311763 - make holiday calendar offerings automatic

Status: NEW

(Calendar :: General, enhancement)

Description

[Matt Kelley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

The main thing I miss from Outlook's calendar is being able to see all of the
holidays. I am not going to take the time to put them all in, so I wish that
they would come preloaded. I can't imagine that it would be that difficult to
include US, Canadian, UK, and European holidays.

Reproducible: Always

Comment 1

[Robin Edrenius]

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?

Comment 2

[Joey Minta]

We have a holidays file list. -> WFM

Comment 3

[Calum Mackay]

see also:

http://www.apple.com/ical/library/

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

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?

Comment 5

[Stefan Sitter [:ssitter]]

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

Comment 6

[Robin Edrenius]

I'll try to fix this.

Assigning to myself

Comment 7

[Robin Edrenius]

Attachment: 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 8

[Joey Minta]

Comment on attachment 204301 [details] [diff] [review]
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.

Comment 9

[Robin Edrenius]

Attachment: Patch v2

Version 2, changing what Joey asked for.

Comment 10

[Robin Edrenius]

Attachment: 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 11

[Joey Minta]

Comment on attachment 204318 [details] [diff] [review]
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.

Comment 12

[Robin Edrenius]

Attachment: Patch v4

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

Comment 13

[Joey Minta]

Comment on attachment 204328 [details] [diff] [review]
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.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 15

[Joey Minta]

(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.

Comment 16

[Robin Edrenius]

Attachment: Patch v5

Attaching a new patch reflecting jmintas comments.

Comment 17

[Mike Connor [:mconnor]]

(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).

Comment 18

[Robin Edrenius]

Attachment: Robins UI suggestion

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

Comment 19

[Joey Minta]

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.

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

(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.

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 22

[Joey Minta]

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

Comment 23

[Joey Minta]

Comment on attachment 204354 [details] [diff] [review]
Patch v5

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

Comment 26

[Pander]

Attachment: Proposed workflow, step 1

Comment 27

[Pander]

Attachment: Proposed workflow, step 2

Comment 28

[Pander]

Attachment: Proposed workflow, step 3

Comment 29

[Pander]

Attachment: Proposed workflow, step 4

Comment 30

[Pander]

Attachment: Proposed workflow, step 5, edit properties

Comment 31

[Pander]

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.

Comment 32

[Pander]

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.

Comment 33

[Pander]

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

Comment 34

[John Vivirito]

Is the following the latest patch at this time?
https://bug311763.bugzilla.mozilla.org/attachment.cgi?id=204354

Comment 35

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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

Comment 36

[Pander]

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?

Comment 37

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 38

[Pander]

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.

Comment 39

[[e-mail]]

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?

Comment 40

[HEMA]

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.

Comment 41

[Pander]

Attachment: Workflow to add public holiday calendar

Comment 42

[Pander]

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

Comment 43

[Pander]

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.