Closed Bug 239431 Opened 21 years ago Closed 19 years ago

Allow choosing multiple exceptions more easily

Categories

(Calendar :: General, enhancement)

Product:
Calendar
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lduperval, Assigned: mostafah)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

patch v1
7.51 KB, patch
jminta
: first-review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8 Hi, when you have more than one or two exceptions, the current UI is no fun. For example, I want to specify an even that coocurs every day, but a few times during the month, I have to add an exception. Doing it one date at a time is slow and boring. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: I would like to be able to click more than one date in the calendar in order to add exceptions in one fell swoop.
Sane RFE. HW/OS -> All. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
I would like to confirm this request too. When I went to put some exceptions in a recurring event that I had, my thought was to check the context-menu for something like a "Add Exception". This would add the instance of the event which was clicked to the list of exceptions. In the end though, any thing that can be done to make adding exceptions would be quite useful. mac
QA Contact: gurganbl → general
I agree. I'm a college student, and was setting up my classes on Sunbird. I wanted to make exceptions from 11/9 to 11/27 for all my classes, IE Thanksgiving break. But I had to input each exception manually. If there were a way to select more then one exception in the pull down menu, or a way to have exceptions that go from date a to date b, that would be swell.
What is perhaps needed (and not? supported by rcf2445) is the ability to block days from being available. That is: Any 'days that are holidays' are NOT to be included, in any match to this recurrence rule ..
I would suggest to get rid of the exception editing feature in the dialog as it obviously is annoying and confusing. there's absolutely no need to have a list of EXDATE's at all since it's perfectly valid to setup a recurring event and later delete the unwanted occurrences directly from any view. internally this creates exceptions on the fly as they would have been created by manually entering them in the exception editing listbox.
Per comment 5 You need to retain the ability to edit / remove exceptions, and therefore the dialog must ALWAYS have this ability. Equally true for viewing occurence details from subscribed or imported calendars. I'm not sure that I would ALWAYS find your method to be the preferred method.
(In reply to comment #6) I'm not sure that everyone has the right understanding what exactly an exception really means and that's possibly why there's so much confusion about the 'exception editing'-stuff in the dialog. currently what's implemented in the event-dialog is a list of EXDATE's, that means dates that mask a regular occurrence (a specific occurrence that is meant not to occur). but an exception is much more than this, an exception is something that differs from the rule. this is much more general, than just masking some specific date. that's why i claim that the datelist in the dialog is useless. it just eats up valuable screen space and doesn't provide any real functionality. my opinion is that the exception editing can be accomplished directly in the views instead of fiddling around with a list of EXDATE's. the user can just drag'n'drop an occurrence to create an exception or delete it to create an EXDATE. we could even allow for copy'n'paste occurrences in order to create/modify/delete RDATE's. as this obviously retains the ability to edit / remove exceptions, it's not true that the dialog needs to keep this feature. i still vote for removing the list from the dialog, any thoughts on this?
Attached patch patch v1 — — Splinter Review
this patch removes the exception handling feature from the recurrence dialog. see above comments for details. the recurrence preview feature (see http://wiki.mozilla.org/Calendar:Event_Dialog) will be submitted within the next few days which will use the screen space gained by removing the exception editing stuff.
Attachment #221796 - Flags: first-review?(jminta)
in reply to comment 7 .. While I agree that the current dialog box uses TOO MUCH space for exception handling, I do NOT agree that removing the ability to see exceptions (or edit them) is a useful improvement. The current dialog's most obvious problem is the assumption that choosing a period (eg. daily, weekly, monthly, annually) will then NOT allow settings from the other periods. Examples: - 2nd Tuesday, of this month, Annually - Tuesday and Thursday, next 4 months There are other occurences, where it appears the dialog could support them, BUT that is not the behavior (or iCal syntax) that results. If you select from quick-picks (ie. 'Third Monday of the month'), there is no way to undo your action (initial radio state: none selected); short of deleting the event OR task (and starting over). I would like to see defined a 'minimum set of functionality', that will meet most user's requirements. (see: Bug 332196, Comment 18) This initially targeted a dialog box to provide full support for view / edit of ANY iCal syntax able to be imported (AND supported) by Sunbird. After some criticisim (that it was 'too complicated for some'), I focused instead on an entry level design, suitable for Sunbird 0.3 (when released). I believe the first step is to agree on a 'function set' (similar to Bug 332196, Comment 18), that will be our next target.
After thinking about this more, I still don't have a good use-case for adding additional, unschedule recurrence options, so if someone can provide me with one, that'd be great. I do, however, still think that it's not uncommon for people to know of cancelled instances of a recurring event when creating an event. Therefore, I'd like to keep the exceptions option in the dialog. Perhaps even more importantly, right now, the event dialog is the 'ultimate repository' of item information. Any changes to an item that can be made elsewhere can be corrected in the dialog and any information presented elsewhere is presented in the dialog. Removing exception support, and forcing the user to use the views to create exceptions breaks this model. That being said, the pattern-preview option that been proposed is very cool, and a huge usability win in my mind. What I'd like to try to do is come up with a balance. The best I had for this was something like: | o Recurs until [05/13/2006 v] | |----------------------------------------------------------| | Exceptions | | |-----------------| |----------------| | | | | Date | | < May 2006 > | | | | -| 05/20/2006 | | 1 2 3 4 5 6 7 | | | | -| 05/25/2006 | | 8 91011121314 | | | | +| 05/26/2006 | |15161718192021 | | | | | | |222324425262728 | | | | | | |293031 1 2 3 4 | | | |-----------------| |----------------| | | [Remove Exception] [Add Exception] | | | | [ OK ] [ Cancel ] | |----------------------------------------------------------| I don't think it's too difficult to move the user's mental model within the Exceptions section from "Removing unwanted instances" to "Fine-tuning the pattern," which this proposal does by allowing for unscheduled options with the +/- column. Additionally, with a minimonth already present, a preview is right at hand. Bold dates would correspond to dates on which the event happens. (see Bug 264150 for a way to do this in the minimonth.) Now, 'exceptions' become 'modifications of the pattern.' If the user clicks 'Add Exception' on a bold date, a negative exception is created (occurrence is removed). If the user clicks 'Add Exception' with a non-bold date selected, a positive exception is created (occurrence is added). The only loss from the original preview proposal is that we're only presenting 1 month instead of 3. mickey, do your usability folks have strong reasons why we need to present 3 months? I don't think many people think in 3-month blocks, but 1-month blocks are quite common. Thoughts? We can move this to m.d.a.calendar if need be.
(In reply to comment #6) > You need to retain the ability to edit / remove exceptions, and therefore the > dialog must ALWAYS have this ability. The latter doesn't follow from the first. There might be other ways to remove or edit an exception. (In reply to comment #7) > we could even allow for copy'n'paste occurrences in order to > create/modify/delete RDATE's. Maybe using a context menu item: 'add item to this set' might work. We could even add ctrl-drag that duplicates the entry in the set. (Less discoverable, but faster) (In reply to comment #10) > Perhaps even more > importantly, right now, the event dialog is the 'ultimate repository' of item > information. Any changes to an item that can be made elsewhere can be > corrected in the dialog and any information presented elsewhere is presented in > the dialog. Removing exception support, and forcing the user to use the views > to create exceptions breaks this model. That statement already isn't true for exceptions. When I change the title of an item in a recurrence set, you can't find that information in the event dialog. So there is really no model that's broken by the proposed removal of the exdate UI.
(In reply to comment #10) > The only loss from the original preview proposal is that we're only presenting > 1 month instead of 3. mickey, do your usability folks have strong reasons why > we need to present 3 months? I don't think many people think in 3-month > blocks, but 1-month blocks are quite common. The basic idea regarding the preview was that the window should be resizeable and the number of minimonths shown should depend on the available space, therefore the layout wouldn't depend on the size of the container. i agree that 1-3 month blocks are quite common, e.g. are sufficient for most cases, but if the recurrence rule spans severals months, it would probably good to be able to see the whole timespan in the preview. that said, wouldn't it be a good idea to mark occurrences in the preview as EXDATE's? this would allow to keep the feature, but would let use remove the plain datelist. if this suggestion doesn't make sense to anybody else, i would still vote for getting rid of the datelist. i completely agree with mvl here.
I just checked the proposal for the dialog changes whether or not Christian initially included the idea to allow for exception editing directly in the preview. Please refer to http://wiki.mozilla.org/Calendar:Event_Dialog, section 'Recurrence Tab Page'. The preview shows three months, the one in the middle shows one of the occurrences to be crossed out, this is meant to be an exception. Just to clarify what i tried to explain in my previous comment. Please note that the proposal would allow to overlay e.g. public holidays to the preview (see the dropdown box below the preview) in order to more easily spot those occurrences that conflict with other events.
In my mind, there are 2 issues at hand here. 1.) Do we need/want to expose exception editing in the dialog. If no, we should just go with patch already here, once it's been reviewed etc. 2.) If we do need/want that, then we need to find a proposal that allows for this, while also allowing for the preview. My comment #10 was my suggestion for how to do this, but I'd be open to any solution that still made it clear to the user the way in which exceptions should be added/removed. dmose, would you mind arbitrating the above?
I've been pondering this and have some thoughts about how to sort it out, but I think I'm gonna need another hour or so to coalesce my thoughts. I'll try and do this tomorrow afternoon.
This is all useful discussion. I stepped into this, only because I considered it had some crossover with bug 332196. I have no objection if my proposed 'entry level' and 'full function' dialogs (for more complex recurrence and iCal syntax) happen at a later date.
I really have no good answer on the question if users need exception or not. I think this is something we should decide in long term based on user feedback. Exceptions are somehow nice, but I think 80% of our users could live without them. That's why I tend towards removing them. For me (I know that not representative), calendaring works fine without these exception rules. I.e. in my daily business I set up a recurring meeting and if one of the scheduled meetings could not take place I'll simply delete the specific meeting from the calendar. Another use case is the one Steven described in Comment #3, but is it too much effort to setup 2 recurring events instead of one which is loaded with exceptions? Taking a look at competing products provides the following result: The only app which allows exceptions is Evolution. Other widely used calendaring tools, such as Outlook 2003/2007, Apple's iCal, Yahoo Calendar, Google Calendar, Zimbra do not provide exceptions.
It's probably worth calling out that we're not talking about getting rid of exceptions (deleting an individual instance of a recurring meeting from a view requires exception support). We're talking about whether it's necessary to expose them in the event dialog. There is an interesting mental model question about the event dialog here, but I think it's different than what people have brought up so far. In particular, I suspect that the mental model worth caring about is not what we've done in the past, but rather what J. Random User thinks the event dialog represents. And by that, I mean someone who has little or no experience with the ICS recurrence model or our 0.x versions. Given the description of the behavior of various clients by Christian, it sounds like for most other clients, the model is "represents more information about the event." Whether users like/dislike this or think that the model should be "represents everything about the event", I can't guess. But with a day or two spent asking people questions, it might be possible to get a better idea. I tend to agree that the list of exceptions as text seems like visual clutter. Is this list likely to be helpful at a glance? Do we really think most users are going to have any idea what a "negative exception" is as opposed to a "positive exception"? Most of the use cases mentioned so far in the bug could be dealt with by selecting multiple items in a view and then using a context menu, drag, or a keystroke. This is not terribly discoverable, however. The use case Joey mentions is the only one I can think of that somebody might run into with any regularity. The reasoning in comment 17 seems pretty solid to me, and erring on the side of simplicity has served the Firefox UI pretty well. So I'd like to suggest that we accept the patch in this bug, and then see what kind of user feedback we get. Popping back out to the views to make exception adjustments doesn't seem horribly painful to me, especially in the cases where the event has been created by clicking or dragging in the view to start with. If we decide we do need to expose exception functionality in the event dialog at some point, we could have a button with a popup and/or allow for drag/context/keystroke stuff in the preview pane. Both of these would seem to be less visually intrusive for the common case than the current widgetry.
The point where the model (user requirements, and expectations) breaks down, is where an externally subscribed / imported calendar uses the rfc2445 ability: to define an event (or task), AND then uses one or more RRULE, EXDATE, RDATE entries to define the pattern. If the user (J. Public) is using our product to create an event / task, assign a pattern (of recurrence), and possibly exceptions - then your arguement is good. In my design (see bug 332196), I seperated (using tabs) the exceptions dates to support scenario per para-1. If para-2 is instead the correct approach for now, then expect no negative feedback.
Comment on attachment 221796 [details] [diff] [review] patch v1 sigh... still betting that we're going to get a bunch of "How do I add exceptions?" questions, but the code-changes here are correct. r=jminta
Attachment #221796 - Flags: first-review?(jminta) → first-review+
(In reply to comment #19) > where an externally subscribed / imported calendar uses the rfc2445 ability: > to define an event (or task), AND then uses one or more RRULE, EXDATE, RDATE > entries to define the pattern. The ability to show those event have _nothing_ to do with the UI of the event dialog. Those two are completly unrelated. So when en event has those recurrecnt rules, it should just work.
(In reply to comment #20) > (From update of attachment 221796 [details] [diff] [review] [edit]) > sigh... still betting that we're going to get a bunch of "How do I add > exceptions?" questions, but the code-changes here are correct. r=jminta > That's entirely possible. But what we're doing strikes me as being in the spirit of the "Make changes quickly and then get them to people so that we can refine them based on observation of user interactions" piece of the Firefox charter. If we do get a sufficient number of those questions, then we will know to take a hard look at discoverability.
patch checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #23) > patch checked in. > FYI: please don't just quote the bug title in the checkin comment, if the patch does something significantly different.
An earlier comment suggested that 80% of users wouldn't care about exposing control of exceptions in the UI. I guess I'm part of the 20%, and there are more of us (there's a discussion in the Mozillazine forum: http://forums.mozillazine.org/viewtopic.php?t=477200&sid=7589d01b17f965ee9bf04f72b2ab4901). The situation in which I would really like to have finer control over exceptions came up this week (Lightning 0.3 in Windows): another obligation preempted a regular, weekly meeting (a recurring even), so I deleted the instance of the meeting event and added an event for the other thing. Then the other thing was canceled -- so of course I deleted that, but there was no way to restore the meeting event. All I could do was create a single event to fill in the missing space. Surely this isn't a rare circumstance. Things get rescheduled all the time. Also, I've sometimes deleted the wrong occurrence of a recurring event, and again there is now no way to undo that. It's not even possible to copy an instance of the recurring event and paste it back in for the deleted date. This isn't just an annoyance, since if the only option is manually recreating a single event to replace a deleted recurring one, the benefits of recurrence are lost. Here's a typical scenario: - user deletes an occurrence of a monthly meeting five months from now because he/she will be out of town - trip is canceled, user wants to restore that meeting event, can only do so by creating a single event - venue of monthly meetings later changes; user changes the location on all future occurrences but the single event that had replaced the delete instance is not change. User is in wrong place, boss gets angry, user is fired (or what have you). I'm sure a lot of people would like exception control restored to the UI (speaking as a Lightning user; I don't know what the state of this is in Sunbird). Perhaps I've completely misunderstood what's happened here. But it looks to me as though this RFE began with someone asking for *more* control over exceptions (being able to specify a whole range) and the final code ending up giving users *less* control (by removing that part of the event dialog).
(In reply to comment #25) Obviously there's the need for some clarification here ;-) I didn't want to sacrifice editing of exceptions, but provide it in a way that really makes sense, is consistent and scales well. the simple listbox with EXDATE's was probably not the best way this feature can be provided. as i already suggested we should think of a nice way to allow for exception editing. in my comment #7 i already made several suggestions. if we can find a conclusion on how we want this feature to be implemented i'd feel comfortable with writing the necessary patches.
ugh, I wish you'd done *both* When I'm setting up recurring events it's classes, etc. that have holidays that I know in advance. I think there are going to be a LOT of events and cases that this is the case, not just a canceled meeting here or there. I'm with jminta in comment #10. I've filed Bug 378443.
Depends on: 378443
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: