338215 - add recurrence summary to main event dialog; ponder recurrence dialog structure

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

To me, the way the event panel works in iCal-in-Tiger seems to do a significantly better job of hiding unnecessary complexity than our current panel.  I think that we probably want to add some short summary like they have (e.g. the repeat/end lines) in our main event dialog.

We might also want to mirror their dialog in the way they have separate popups for the various complex chunks.  Or maybe not.  If we decide that's the right thing to do, we should probably spin off one or more bugs for that work.

Comment 1

[Michael Büttner (no reviews TFN)]

i assume you're refering to our event dialog, please correct me if this is wrong. but i totally agree that the arrangement of the dialog is less than perfect. one way to address this issue is using tabs, but i admit that this is not a perfect solution in our case, since the various chunks can not be equally distributed to the different panes (some panes would contain much more stuff than others). personally i also don't like popups in any form or shape (other windows popping up, etc).

maybe the following idea could help solving this problem. what about putting the different chunks into some kind of groups, where those groups can be collapsed/expanded? assume the dialog itself does not resize itself depending on the content, but has a vertical slider which can be used to scroll through the different bits and pieces (common stuff, recurrence pattern, rules, attendees, free/busy, etc.). each of those parts can be collapsed or expanded. this is a bit like the panel in ical works, apart the fact that we'd host this stuff in a separate window. it's also very similar to how the ui in 3ds max works. see http://www.codeproject.com/wtl/wtlrolldownctrl.asp for how this could look like.

Comment 2

[Christian Jansen]

Attachment: Anti Complexity Proposal

Comment 3

[Christian Jansen]

(In reply to comment #0)
> To me, the way the event panel works in iCal-in-Tiger seems to do a
> significantly better job of hiding unnecessary complexity than our current
> panel.  I think that we probably want to add some short summary like they have
> (e.g. the repeat/end lines) in our main event dialog.
> 
> We might also want to mirror their dialog in the way they have separate popups
> for the various complex chunks.  Or maybe not.  If we decide that's the right
> thing to do, we should probably spin off one or more bugs for that work.
> 

I agree that Apple's iCal Event-Dialog looks well designed and not too complex.
What I personally don like is that it presses users in some kind of sequence. Which needs to be repeated on and on when creating more complex events

For example - Recurrence:
Scenario: Create an Event, Wednesday 11:00am to 12:00, which repeats bi-weekly, 5 times

Apple iCal:
- Create Event in Week View (Click Drag)
- Type Event Title
- Set Repeat Drop down to Weekly
- Select End
- Set 5 Times

Creating the event is done within 2 steps -- just for specifying the recurrence rule 3 steps are needed, whereby two of the three steps claim a decision from the user.

I've created a proposal which reflects your thought regarding complexity.

The basic idea is to offer users a solution with no tabs. For reducing unnecessary complexity the Event dialog offers only items really needed.

Like an accordion the dialog expands on demand. A possible demand could be the scenarios that one wants to assign a repeat pattern to an event. Therefore the user selects the high level repeat pattern. This calls automatically a panel which allows users to defined the details of the repeat pattern

Same could be possible for inviting other attendees.

The solution reflects the idea Michael described in comment #1. The main difference is that the layout is primarily aligned horizontally.

Please find a mock-up of the idea attached at this issue.
https://bugzilla.mozilla.org/attachment.cgi?id=223035

Maybe the whole stuff is some kind visionary, but I would like to hear your opinions on that.

Comment 4

[Joey Minta]

Attachment: streamline common recurrence options

This patch optimizes for the common recurrence cases, as discussed in the newsgroup.  This will a) Make it clearer to users what type of recurrence is associated with an event and b) Allow users to more quickly enter the more common types of recurring events.

Screenshot to follow

Comment 5

[Joey Minta]

Attachment: event dialog with new menu

Screenshot of the new dialog, with the weekly option chosen.

Comment 6

[Michael Büttner (no reviews TFN)]

I would like to point to my concerns mentioned in the appropriate thread http://groups.google.com/group/mozilla.dev.apps.calendar/browse_frm/thread/0acb8e282c185253/8ba0aadaca24a821#8ba0aadaca24a821
I find that those concerns were not addressed at all.

I strongly discourage from implementing this feature before we found consensus regarding the general layout of the dialog. first of all, it deviates from the proposal for the event dialog [http://wiki.mozilla.org/Calendar:Event_Dialog] and second i don't feel that the discussion in the above mentioned thread came to any conclusion.

generally, i don't like how features find their way into the product in this rather ad-hoc way. i would suggest that we first define the requirements and carefully prepare the appropriate specifications and then start implementing the agreed features instead of spinning off feature implementations at will. this would mean that we should first have the up-to-date specification available at the wiki and then start the implementation of the missing features.

Please don't get me wrong, I generally have no problem with this specific feature at all, but it simply doesn't work if we decide to separate the chunks of the dialog into tab pages. Therefore it doesn't make much sense to implement this feature before we didn't carefully deliberate the decision.

Comment 7

[Andrew N Dowden]

I also have issue with how these features are being added.

We have 3 different components to (perhaps partially) be included:
(a) some simple 'quick picks' (and comment 5 has some merit, as well as issues)
(b) a 'minimum spec' list of features for recurrence, for Sunbird 0.3
  - this needs to be defined (probably as wiki content), based on various discussions / opinions on target group's needs.
(c) what possible future 'more complete spec' capability, for more complex recurrence, and to show what is in effect through import or subscribe.
 - the functionality currently supported (in iCalendar syntax) will probably be larger than initially defined for (b).
 - When/if these features will be implemented; OR do we say: "Too hard, go check the exported iCalendar syntax."
 - this will need to (eventually) address what can and can't be defined in iCalendar (rfc2445) syntax, and how more complex 'recurrence sets' should be addressed in UI form.

Comment 8

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!

Comment 9

[Matthew (lilmatt) Willis]

Not going to make the 0.3 train.

Comment 10

[Joey Minta]

Comment on attachment 224622 [details] [diff] [review]
streamline common recurrence options

I'd really like to see this make 0.5, since in my mind, it's a big usability win.  Shifting some reviews around to try and make that happen.

Comment 11

[Joey Minta]

Comment on attachment 224622 [details] [diff] [review]
streamline common recurrence options

As I understand the current plan, this code isn't useful.

Comment 12

[Matthew (lilmatt) Willis]

Not going to make the 0.5 train.

Comment 13

[Simon Paquet [:sipaq]]

This works in the new dialog.