Open Bug 366914 Opened 13 years ago Updated 1 year ago

make default calendar for new items more obvious


(Calendar :: General, defect)

Not set


(Not tracked)


(Reporter: mvl, Unassigned)



(Keywords: uiwanted)


(1 file)

I personally never liked the way that the selected calendar in the listbox is
the calendar in which new items are created. There is no UI hint to that
anywhere. You just have to know it.
Maybe we need some checkbox in the listbox? One that gets remembered across
Also see some of the comments in bug 350323
I've played around with this since my post in the original bug report. I'm not sure this is the ultimate solution, but it would probably help. 

The main problem is that the Calendar list doesn't make it obvious that the highlighted item is the "default" for new tasks/events. Doing something like what I've done here at least draws a relation between the calendar list and the list in the task/event dialog. 

What else could you do? The only thing more I could think of would be to not tie the default calendar to what's "highlighted" in the calendar list (my radio button in the picture just follows the highlight at the moment). Then you could also add a "Default Calendar" option to the calendar's properties dialog.
Duplicate of this bug: 375638
Comment on attachment 251855 [details]
Possible solution v2 (lightning)

mvl, I'd be happy to hear from you what you think about Luc's ideas. Do you think that would fix this bug? If not, maybe you have an idea how it could be better solved.

I personally would like either other icons or just a checkbox and a radiobox.

The only problem I see is that a standard user might not know what to do with such icons and be confused as to what the icons/checkboxes do.
Attachment #251855 - Flags: ui-review?(mvl)
I'd like to see some combination of <a href="">Bug 313948</a>(Persistent read-only state), a default calendar option in the preferences, and colorizing the calendar menu in the New Event dialog to match the color of the calendar you are posting to.  A default checkbox in the listbox would help to.

I see the process going something like this:

1. User chooses  "New Event" or double clicks a date to create an event.
2. User doesn't notice which calendar was highlighted, but sees that the new event is going on the orange calendar.  The event should be on the green calendar, so the user switches calendars.
3. If the default calendar had been green that wouldn't have happened, but since colors are very quickly recognized the error was corrected before being committed.
Duplicate of this bug: 402025
Flags: wanted-calendar0.8+
Duplicate of this bug: 405594
  If the calendar was shown as hidden (one of those yellow exclamation warning icons with mouseover text?) in the New Event dialog the user would have a clue that the calendar is hidden, and therefore the user would have an indication when they go back to add the item again with an eye to what they did wrong (as they are likely to do).
Colors are nice, but not very accessible. Wording is very important.
"Default" calendar tells me nothing. "Event-save" is more indicative.

Given a calendar list, the radio button column next to the calendar
entries could have a title like:

   Default for 

When creating a new event, the dialog could have a dropdown that 
shows calendars, with the initial selection set to the default.
Title for the dropdown would be

  Save events to:

I very much like the idea of a publish/subscribe mechanism. But
that is very different from calendar sharing. When I subscribe
to an organizational event calendar, maybe I shouldn't be able
to edit it. (Or maybe I should--Wiki fashion. Interesting idea.
But it needs to be a conscious choice, I should think.)

event-save feels weird, because 1) it applies to tasks as well as events, and 2) it's not really about saving, it's about "new events/tasks".   Maybe what we're talking about is some notion of a "Main" calendar?
Comment on attachment 251855 [details]
Possible solution v2 (lightning)

This screenshot/mockup is outdated. Removing ui-review.
Attachment #251855 - Flags: ui-review?(mvl)
If talking about wording, why not call it the "active" or "working" calendar?

I still think we need a visual cue to identify the current calendar that events are added to. At the very minimum the list in the Add/Edit event and task windows should include the color of the calendar, which at least in part reproduces what I had done with the "eye" and "star" columns (although I still like that idea too.. but then I came up with it so I'm probably biased). I think the eye especially is very representative of what the current checkbox actually is and doesn't show.. and I don't think it's something that would confuse the masses... the star maybe.

Martin, ya it is very outdated. I haven't had time to try to mod the latest version(s) for myself, although I've been meaning to check it out.. And just a clarification, that's an actual screenshot of it working that way, it hasn't been photoshoped in any way, if that's what you meant by "mockup".
Cc'ing Christian, our UI lead and guru. ;)
Version: Trunk → unspecified
We also have different capabilities of calendars regarding tasks and events. All my "Event" calendars are Google-based, but Google Calendar does not support Tasks (at the moment). So I have yet another calendar dedicated to tasks.

Wouldn't it be worth then to add this capability per calendar provider, and have different lists of calendar values for Tasks and Events ?
We would then even have an "active task calendar" and an "active event calendar" at the same time.

The main concern is when using the Today pane, when the "active calendar" is not visible beforehand.

Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: wanted-calendar1.0?
Duplicate of this bug: 461373
Duplicate of this bug: 602296
Duplicate of this bug: 482984
Flags: wanted-calendar1.0?
Can we at least get a configuration value in the Preferences dialog to set a default calendar?
I keep getting bit b/c it selects a calendar I don't expect by default.

Surely that is something we can get in the next release, no?
You need to log in before you can comment on or make changes to this bug.