Allow easily adding holiday calendars

Bug #174672 reported by Pander on 2007-12-07
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Sunbird
Confirmed
Medium
lightning-sunbird (Ubuntu)
Wishlist
Unassigned

Bug Description

For both lightning and sunbird, please implement an extra option when adding a new calendar. Next to 'On My Computer' and 'On the Network', offer an option called 'National Holidays on the Network'. This will offer the user to select 0 or more calendars from http://www.mozilla.org/projects/calendar/holidays.html

Implementing this features will allow more people to use the same shared but read only holiday calendars which are managed in a central place, leaving less margin's for errors in common data as national holidays.

There are a set of remote calendars for download with all the holidays:
http://www.mozilla.org/projects/calendar/holidays.html

Is that what you're looking for?

We have a holidays file list. -> WFM

What about making this more integrated: say, includin the URL appropriate holiday files in the locale file, and then making some UI that makes it trivially easy to subscribe?

*** Bug 317712 has been marked as a duplicate of this bug. ***

I'll try to fix this.

Assigning to myself

Created attachment 204301
Patch v1

Here's my first try on this. Did a few comments in the code, if they're un-needed, please let me know and I'll remove them.

Comment on attachment 204301
Patch v1

This looks like a good start.

+ // Get Holiday calendar URL from the prefs
+ var url = Components.classes["@mozilla.org/preferences-service;1"]
+ .getService(Components.interfaces.nsIPrefService)
+ .getBranch("calendar.").getCharPref("holidayCalendarURL");
I really don't think a preference is called for here. Preferences are things users might want to change, but this will only happen the first time Sunbird is run. That means that changing it will have no effect. Why not just use srGetStrBundle() and use that to get the url/name directly?

+ holidayCalendar.name = name;
Maybe we want to give the calendar a separate color too? That way the events don't get mixed up between 'Home' and 'Holiday'.

+# Holiday calendar file
As I'm learning, you're going to need to give translators a little more info for what they should put here. Probably expand this comment to include a reference to the general holiday's page, so they can get a url from there.

Just a general nit: include a blank line between code blocks, it makes the code more readable.

Created attachment 204314
Patch v2

Version 2, changing what Joey asked for.

Created attachment 204318
Patch v3

Making a few changes suggested by mvl and jminta per IRC:

* Adding a try/catch to handle if holidayCalendarURL isn't set.
* Changing the localization note (I'm not sure if it is good now either though) =)

Comment on attachment 204318
Patch v3

+ try {
+ var url = srGetStrBundle("chrome://calendar/locale/calendar.properties")
+ .GetStringFromName("holidayCalendarURL");
Style: try/catch defines a code block, so you need to increase your indenting here. (Anytime you use '{' indenting should change.)

Style: It's best to minimize the amount of code enclosed in a try block, since it can hide other errors. In this case, there's only one line that you expect to throw an error, so the catch should come right after it.

As mvl pointed out, the other thing that can happen here is that the localizer left holidayCalendarURL blank (but defined it) In that case, GetStringFromName won't die, and we'll create a calendar with a blank url, which is bad. So, after you get the string, you need to check to make sure it actually contains useful data.

Created attachment 204328
Patch v4

This patch should cover all of those cases.
I also changed the indenting.

Comment on attachment 204328
Patch v4

This is looking good now. The only things I have left are nits.

First of all, bring back at least the introductory comment, so people can quickly see what you're doing with this block. You might also want to include comments about why 'try' and 'if' are needed here.

+ var url
semicolon please.

+ try {
+ url = srGetStrBundle("chrome://calendar/locale/calendar.properties")
+ .GetStringFromName("holidayCalendarURL");
+ }
+ catch(ex) {}
1.) Standard indenting is 4 spaces. You see to have done more. (same in the if block)
2.) the closing brace ('}') should be aligned with the start of the code that opened it. In other words, it should be directly under the 't' in 'try'
3.) 'catch' goes on the same line as the closing brace of try. (see line 199 of this file)

+# LOCALIZATION NOTE (holidayCalendarURL):
Now that we've gone through all this trouble to handle cases where localizers don't set this, be sure to mention that it's OK for them to leave it blank if there isn't a holiday file for their locale.

Nice work here. I think we'll get some nice user-feedback on this feature.

I'm not totally sold that just automatically adding the locale calendar is the right thing to do. It seems to me that there are so many cases when this is going to be not something the user wants that it makes sense to be a bit more conservative here. Cases include users who live in places which are not likely to see a lot of localizations (eg en-CA, de-AT) since existing ones (eg en-US, de-DE) tend to be good enough, or places that have few enough people that they don't see localizations until much later in the cycle.

A couple of possible strategies I can think of include:

a) have a menu item that simply brings up <http://www.mozilla.org/projects/calendar/holidays.html>. This could either be in a <browser> element in Sunbird/Lightning or the OS-default web-browser. The latter presumes that we automatically register ourselves as the OS-default ICS calendar and automatically subscribe to any calendars when handling such a file.

b) have some sort of slightly more sophisticated interface, perhaps triggered from a menu item, that knows about the set of available holiday calendars and uses the locale-calendar as the default choice there

(In reply to comment #14)
> I'm not totally sold that just automatically adding the locale calendar is the
> right thing to do. It seems to me that there are so many cases when this is
> going to be not something the user wants that it makes sense to be a bit more
> conservative here.
> a) have a menu item that simply brings up...
> b) have some sort of slightly more sophisticated interface, perhaps triggered
> from a menu item,

Given that this is an action that the user is only going to perform once, I don't think that sticking this in a menu-item is a good idea. To me, menus should be constant (so we shouldn't remove the menu-item after its done), which means that after the user makes a decision about the holiday file, the menu-item is going to be hanging around for the life of the program useless. I like the currently proposed model for the following reasons:
1.) It takes 0 clicks to subscribe to the calendar and 2 clicks to remove. Any other solution involving menu-items will be more complex.
2.) Since removing the calendar is so easy, this seems to be a simple addition to the required tasks to setup/customize Sunbird.
3.) It aids in increasing the discoverability of calendar-colors, multiple calendar file, and the calendar checkboxes.

It's the simplicity here that's the strong point of this solution, in my mind.

Created attachment 204354
Patch v5

Attaching a new patch reflecting jmintas comments.

(In reply to comment #15)
> Given that this is an action that the user is only going to perform once, I
> don't think that sticking this in a menu-item is a good idea. To me, menus
> should be constant (so we shouldn't remove the menu-item after its done), which
> means that after the user makes a decision about the holiday file, the
> menu-item is going to be hanging around for the life of the program useless.

You're assuming that users always choose correctly, and never revisit their choices. That's a pretty dangerous assumption.

> I like the currently proposed model for the following reasons:
> 1.) It takes 0 clicks to subscribe to the calendar and 2 clicks to remove. Any
> other solution involving menu-items will be more complex.

Calendaring is not a stone-simple concept, so the most simple solution is not necessarily the right solution. Giving the user flexibility probably is..

> 2.) Since removing the calendar is so easy, this seems to be a simple addition
> to the required tasks to setup/customize Sunbird.

And if you remove it, how do you add it back?

> 3.) It aids in increasing the discoverability of calendar-colors, multiple
> calendar file, and the calendar checkboxes.

None of these are simple concepts, so what it almost seems like you're doing is pushing the concept on a user where it may be unnecessary or annoying. This, to me, seems like a conflict with your first argument.

Conceptually, holidays are a part of the structure of the calendar, they're not really events that you want conflicting with items you add, they're context for the day in question within which you can add events. Just adding an all day event doesn't really present things like a traditional calendar, and ideally "dinner at Mom and Dad's" on Thanksgiving doesn't show as a conflict simply because of how we choose to represent a holiday. If at all possible it should reflect in the view as something fixed and unalterable yet subtle, with an option for what country's holidays (you could get fancy and let people add multiples, i.e. Canada AND the U.S. for those of us who live in one and work with people in the other).

Created attachment 204715
Robins UI suggestion

Here is my current UI suggestion (Some re-wording and stuff might be needed).

I think this bug has stimulated a lot of very good discussion, but I'd like to try to bring back some of the focus here, since we seem to be trailing off in several directions.

A: Lucy/mconnor both point out that national holidays should not be treated like normal events. In some respect, this is like bug 160298. Holiday files need to interact with the composite in a special way, so that they appear as visual indicators, rather than user-scheduled events.

B: dmose and I have also both started discussing the need for greater ease of access to calendar files that are publicly available on the internet. In this respect, I believe the ultimate solution is to introduce a 'or search known calendar collections' option to the URL page of remote calendar creation in the wizard.

The original proposed solution I was driving towards here (indicated in the patches attached) introduced no new UI in an attempt to take a first step towards both of these goals. We begin to treat holiday files in a special way, but automatically subscribing a user to a list of them (displayed in a distinct color) when Sunbird is first launched. We also reduce the need for users to go out and find these calendars, by automatically providing the most likely calendar they will need.

Many of the comments and criticisms that I've heard about this seem to be arguing more from the point of view that this patch does not go far enough. (Comment #17 especially). The points made there are all perfectly relevant, but I'm of the belief that trying to address them would be taking too large of a step at once (at least given available development resources).

What needs to be decided then is: Is this patch an acceptable first step along the paths to the two above goals? It certainly is not the final answer to either of them. If we decide that this is not an acceptable solution, then perhaps this bug needs to be closed as invalid, and a new bug with a more clearly established goal needs to be filed.

One of the things I'd propose would be to try to develop some common use cases for holiday files, probably via a blog post.
-What percentage of users subscribe to a holiday file?
-What percentage of our users subscribe to more than 1 holiday file?
-What percentage know holiday files exist/ where to find them?
-What percentage use the holiday file directly corresponding to their locale?

If we can get answers to these questions, it might help indicate how appropriate this patch is.

Finally, I'm opposed to the new proposed UI. Separating out calendar subscription from the calendar list, into the preferences, seems very counter-intuitive. If anything, this belongs in the calendar-creation dialog, until such time as we can actually treat holidays in a non-event type way.

(In reply to comment #19)
>
> B: dmose and I have also both started discussing the need for greater ease of
> access to calendar files that are publicly available on the internet.

I would actually go so far as to say that even "search known calendar collections" is really just part of a higher level goal of providing useful integration with stuff on the web (eg existing ICS resources, calendaring sites, mapping sites for locations, etc).

> In this respect, I believe the ultimate solution is to introduce a 'or search
> known calendar collections' option to the URL page of remote calendar
> creation in the wizard.

It could make sense to have an entry point there. I would argue that in the short term, it would make sense to simply have a menu item that links to a web page of Internet calendaring resources, and one of the things on that page would be a link to another "search for a holiday calendar" page.

> Many of the comments and criticisms that I've heard about this seem to be
> arguing more from the point of view that this patch does not go far enough.
> (Comment #17 especially). The points made there are all perfectly relevant,
> but I'm of the belief that trying to address them would be taking too large of
> a step at once (at least given available development resources).

Yes, I completely agree. Right now, in both the Sunbird and Lightning worlds, the important goal is to "ship something that is usable by users and based on the refactored back-end". If we can do something easily now to support holiday stuff, great.

> What needs to be decided then is: Is this patch an acceptable first step along
> the paths to the two above goals? It certainly is not the final answer to
> either of them. If we decide that this is not an acceptable solution, then
> perhaps this bug needs to be closed as invalid, and a new bug with a more
> clearly established goal needs to be filed.

This sounds to me like an excellent framing of what we need to sort out now, although I think just adding a menu item as described above would be another possible simple solution.

> One of the things I'd propose would be to try to develop some common use cases
> for holiday files, probably via a blog post.
> -What percentage of users subscribe to a holiday file?
> -What percentage of our users subscribe to more than 1 holiday file?
> -What percentage know holiday files exist/ where to find them?
> -What percentage use the holiday file directly corresponding to their locale?
>
> If we can get answers to these questions, it might help indicate how
> appropriate this patch is.

Its not clear to me how blogging is likely to result in us having believable answers to this questions, but perhaps Im not understanding exactly what youre proposing.

Honestly, to me this sounds like the sort of thing that a first setup or calendar creation wizard would be perfect for. One panel could be "Add events to this calendar" and allow the user to pick from a list. Perhaps they want stat holidays and Jewish holidays. Perhaps they want phases of the moon. Be helpful when it comes to creating the calendar they want, but don't assume that you know what they want.

We should look at this problem in the newsgroups to figure out the best way to address it.

Comment on attachment 204354
Patch v5

Cancelling review until we can get a proper answer the UI questions here.

*** Bug 273376 has been marked as a duplicate of this bug. ***

Pander (pander) wrote :

For both lightning and sunbird, please implement an extra option when adding a new calendar. Next to 'On My Computer' and 'On the Network', offer an option called 'National Holidays on the Network'. This will offer the user to select 0 or more calendars from http://www.mozilla.org/projects/calendar/holidays.html

Implementing this features will allow more people to use the same shared but read only holiday calendars which are managed in a central place, leaving less margin's for errors in common data as national holidays.

Pander (pander) wrote :

Also set read-only to true for these calendars.

John Vivirito (gnomefreak) wrote :

I will concider this for 0.8 in Hardy+1

Changed in lightning-sunbird:
assignee: nobody → mozilla-bugs
importance: Undecided → Wishlist
status: New → Incomplete
John Vivirito (gnomefreak) wrote :

Please ask upstream to add this feature as they add all Mozilla radio buttons.

Changed in lightning-sunbird:
status: Incomplete → Won't Fix
John Vivirito (gnomefreak) wrote :

When you file this bug upstream please add it to the packages or leave a link and i will add it and follow it.

Changed in lightning-sunbird:
status: Won't Fix → Incomplete
Pander (pander) wrote :
Changed in lightning-sunbird:
status: Incomplete → Confirmed

*** Bug 437746 has been marked as a duplicate of this bug. ***

Pander (pander) wrote :

Above link is duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=311763 Please inquire via this URL about development status.

Pander wrote:
> Above link is duplicate of
> https://bugzilla.mozilla.org/show_bug.cgi?id=311763 Please inquire via
> this URL about development status.
>
>
Thanks i added it as upstream task.

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

Changed in infodomestic-spatial-objects:
status: New → Invalid
Changed in sunbird:
status: Unknown → Confirmed
John Vivirito (gnomefreak) wrote :

Removing mozillateam from this as we all get the bug reports anyway.

Changed in lightning-sunbird:
assignee: mozilla-bugs → nobody

Created attachment 353960
Proposed workflow, step 1

Created attachment 353961
Proposed workflow, step 2

Created attachment 353962
Proposed workflow, step 3

Created attachment 353963
Proposed workflow, step 4

Created attachment 353964
Proposed workflow, step 5, edit properties

I've added a proposed workflow which can be implemented easily. Not that retrieving the list of URLs can be done dynamically and as a fall back should get the list out of a configuration file that is shipped with the application. The result of downloading the list of URLs should be stored in the shipped config file that will be upgraded in this way.

In this way, it is possible to add more than one holiday calendar as to the earlier proposition. I hope this proposed workflow will spark implementing and fixing of this issue.

I understand that automatically transforming certain URLs listed at
  http://www.mozilla.org/projects/calendar/holidays.html
like:
  http://www.mozilla.org/projects/calendar/caldata/CalendarBahai.ics
and:
  http://www.mozilla.org/projects/calendar/caldata/BelgianDutchHolidays.ics
to:
  Baha'i Holidays
and to:
  Belgian (Dutch) Holidays
is a challange.

For starters it would require:
  http://www.mozilla.org/projects/calendar/caldata/CalendarBahai.ics
to be renamed to:
  http://www.mozilla.org/projects/calendar/caldata/BahaiHolidays.ics
and the result of space insertion will be:
  Baha'i Holidays
and:
  Belgian Dutch Holidays

From there, it is up to the user to change the name of the calendar while adding a holiday calendar or editing properties of an existing one. Note that the example in the proposed workflow in step 2 should remove the accent ' and brackets () from the example names in the single selection list.

Can you all provide feedback on the recently proposed 5 workflof steps? Thanks

John Vivirito (gnomefreak) wrote :

This might land in 1.0b1 that is the last release of Sunbird, There is no info on if and when they will continue to support Sunbird. The last version will be 1.0b1 they will not release a final version of Sunbird as it stand. Lightning will continue on.

We might want to use live.mozillamessaging.com for this. Providing nice ui and integration might make a nice student project.

Any progress on this issue? In my opinion it is not that difficult to implement proposed workflow, as is documented in the attachments. No need to use live.mozillamessaging.com for this at all. Could someof the lead developers give some advice on this issue?

Changed in sunbird:
importance: Unknown → Wishlist

Pander, I was rather thinking we might want to move the holiday calendars to a webservice on live.mozillamessaging.com that allows getting the list of calendars as a json or xml object.

If you are still interested in adding the UI here (I know, its been a while), please let me know and I'll give you some help to get started.

Thanks for the offer. However, I don't have the time or desire to implement it myself. Please leave this feature request open for others (volunteers or students) to implement it.

The USA Holiday calendar, downloadable from the Lightning Web site does not include Jewish holidays.

Can someone simply add them to the existing calendar, or create a calendar that can be imported separately, to add to the existing calendar?

http://www.mozilla.org/projects/calendar/holidays.html

 some calendar holiday files available for download. You can either download and then import them into Sunbird or Lightning or you can just subscribe to these calendars by copying their URL and then adding them as new remote calendar files. More information on installing a holiday calendar can be found in the Adding a holiday calendar article.

Created attachment 815254
Workflow to add public holiday calendar

See also https://bugzilla.mozilla.org/show_bug.cgi?id=925245 for the newly proposed workflow.

Note to also take into account that a country can have multiple Mozilla holiday calendars, each for a language spoken or relevant for that country. Usually an alternative/additional calendar is in English for international purposes.

Changed in sunbird:
importance: Wishlist → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.