Closed Bug 357012 Opened 18 years ago Closed 9 years ago

Week number support in multiweek/month view

Categories

(Calendar :: Calendar Frontend, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: matp75zilla, Assigned: bv1578)

References

Details

Attachments

(4 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061003 Firefox/2.0
Build Identifier: Thunderbird 1.5.0.7 (20060909), ligthning 0.3 (2006100618)

When planning something, people are usually asking me something like 
" do you prefer to do this in week 46, 47 or 48 ?"
To answer, using the week view is inefficient because I need a more global view on my agenda to be able to answer.
The month (or a multiweek) view allows to have a better view on the agenda.
the problem is that the week number is missing from the month view.
So this bug is about adding this information to the month view.
I think it should be at the left of each week.
 

Reproducible: Always
I have to agree on this one cause this a feature I also miss!
Sure the Week # is important in all kind of views, month, day and not only on week view.
I agree too. This, while it may seem minor, is IMO one of the most serious flaws in Lightning.
Flags: blocking-calendar0.5?
Component: Lightning Only → Calendar Views
OS: Windows XP → All
QA Contact: lightning → views
Hardware: PC → All
Summary: Week number support in the ligthning month view → Week number support in multiweek views
Version: unspecified → Trunk
This doesn't block 0.5 but we'd likely take it if there's time left.
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Please make this feature optional in month view.

I never need to know the week number and would prefer not to have information on my monthly calendar that is irrelevant to me and that takes away screen space.  Please at least consider letting people disable it somehow such as with "display: none" in UserChrome.css.
Confirming. The week numbers were displayed in Sunbird 0.2 where the design of the month and multi-week views was slightly different, but apparently they were removed at some point.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-calendar0.5-
Summary: Week number support in multiweek views → Week number support in multiweek/month view
Here in Sweden (I don't know about the rest of the world) we use week numbers a lot. Even if the week numbers is shown in all views, it is too hard to see what number a week has in multiweek and month view.

The poor usability in the new Sunbird (0.9) when navigation by week number is the sole reason that I registered here.
Christian, any opinion how this would best fit in?
Keywords: uiwanted
Keywords: helpwanted
Proposal to implement CW (Calendar Weeks) number:

Priority 1:
To have the best overview, put it on the left side of the Mini-month in the today pane.
That is the one, many people have open even when in eMail view.


Priority 2:
BESIDE above (Prio 1) ALSO put in the monthly view of the calendar view.

Thanks for working on this.
That is an important feature for the daily use.

Rolf
As of today, 2012-05-18, there have been several GUI changes such that:
* CW is shown to the left of "Day, Week, Multiweek, Month" tabs
* mini-month is not inside "today pane" (what's the name of the pane it's in, by the way?)

So week numbers are also available.  It just needs to be displayed in the mini-month as well as in Multiweek & Month view.
There is one other thing missing.  In the corporate, educational and government world, when calendar week 1 starts varies.  

Often called "work week", it may start on the first week of the fiscal year, the first week of the calendar year that has at least n work days, the first day of the year, etc.  Some years have 53 work weeks...

Where I live, municipal fiscal years often start on 1-Jul, as do University calendars.  The US government's fiscal year starts on 1-oct of the previous year.
People's tax years can begin on arbitray dates.  And then there are various cultural years...

I don't think we need a new infinitely expressive language for this "creativity", but it would be nice to at least be able to specify that "For this calendar, work week one of year n starts on date x".  It would suffice to be able to input a CSV file - corporate types love spreadsheets, so that way the GUI comes for free...

Perhaps the simplest approach would be to have a special recurring event that marks the first work week of the year.  Events already have recurrance patterns...so if there were a "Week Number 1 starts today" flag, the calendar could just start counting from the nearest such event before a given date.  And yes, that means you could have a new "week 1" every day - not that the degenerate case is useful :-)


E.g. One might well have (and these are real examples!):

Home,2012, 1-jan-2012
DumbCorp,2012,20-Dec-2011
DumbCorp,2013,4-Jan-2013
USGOV,2013,1-Oct-2012
"My Town",2013,1-Jul-2012
(In reply to tlhackque from comment #13)
> There is one other thing missing.  In the corporate, educational and
> government world, when calendar week 1 starts varies.  
This looks to me like a new feature request which would deserve a new bug, although I must say I think this would be much better placed in an extension. Not everyone is in a such environment. I think it would be good to add additional UI to the views (in an extension) that shows the fiscal week in addition to the standard calendar week.
Some business tasks use week numbers and it's then a mandatory reference when you work with a calendar tool like Lightning.

Today (TB31/LG3.3) a short "Week: X-Y" is present at the top of the calendar but this isn't sufficient to locate the week at the first glance.

It would be great when Lightning will display the week number at the left of the first day of the week (multiweek or month view).

Thanks
Attached image proposal β€”
I have a few wip patches that add labels with the week number in two different ways in month/multiweek-views and in the minimonth as shown in the screenshot.

The first one places the labels in a position that is not ideal but since it doesn't waste horizontal room in the view, it might be preferable, in particular for those who don't need the week number.
The second one takes 12 pixels of horizontal room that is something minimal. Since the text "W" can be longer depending on locales, I think that the vertical oriented text is the only choice to keep the room small.
The minimonth has a new column with the numbers of the weeks but overall the width is the same. 

I'm not sure whether we want to fix the issue in this way or in another way or by making the changes optional via preferences or other way (for many users the indication of the weeks in the navigation bar is already sufficient).
If we decide some detail we can implement this in some way.
Whats the longest that the calendar week abbreviation is localized to? In English its CW, in German its KW. Personally I think placing it in the header of the first day box is sufficient and doesn't look crammed. It also doesn't waste extra space. If we go for the second option I definitely think we need to add a visible preference for it, otherwise we can get away with suggesting to use a userChrome.css to get rid of it.

Regarding the calendar week in the minimonth, I think it needs some more visual distinction from the actual days. In February 2017, the first week of February is week 5 and the Saturday just before it is the 4th. So you have 4 and 5 next to each other. The line is thin, so either a thicker line or changing the color of the week name. 

Maybe it also makes sense to put the week numbers to the left in the minimonth?

Also, if we go for the second option of having the week number vertically, maybe we can find another smart solution for the day/week view, so we can get rid of the calendar week indication in the header area?
(In reply to Decathlon from comment #16)
> Created attachment 8485517 [details]
> proposal
> 
> I have a few wip patches that add labels with the week number in two
> different ways in month/multiweek-views and in the minimonth as shown in the
> screenshot.

I like the rotated label (the screenshot on the right) much more. Anyway, is there a chance it will be implemented soon since the request is there for almost nine years ?
(In reply to Petr Vones from comment #19)
> (In reply to Decathlon from comment #16)
> > Created attachment 8485517 [details]
> > proposal
> > 
> > I have a few wip patches that add labels with the week number in two
> > different ways in month/multiweek-views and in the minimonth as shown in the
> > screenshot.
> 
> I like the rotated label (the screenshot on the right) much more. Anyway, is
> there a chance it will be implemented soon since the request is there for
> almost nine years ?

for the short term:
I made an add-on analogous to the 1st suggestion by @Decathlon (i.e. the left screen shot).
In my opinion --and as @Decathlon already mentioned-- it is less intrusive / easier to ignore, if you do not need or want it, but also easy to find if you want to known the calendar week 

It is still under review as add-on, but also published as OpenSource on GitHub
https://addons.mozilla.org/en-US/thunderbird/addon/show-calendar-week/
https://github.com/russaa/thunderbird-addon-show-cw/
Flags: needinfo?(bv1578)
OK, so I'm going to do the first case (the one with the labels inside the first day).
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Flags: needinfo?(bv1578)
Attached patch patch - v1 (obsolete) β€” β€” Splinter Review
This is a first patch.

My doubts concern the minimonth:
- do we want the week numbers in the minimonth? I think that if someone is used to use the week number this is somehow necessary since the minimonth is the first place where searching for a date, but an eighth column makes the days columns a bit smaller (3 pixel less) because the overall width is the same. It doesn't reduce usability and, personally, I prefer to maintain a minimum overall width instead of larger days columns;
- the look of the minimonth. The column with the week numbers should be different and, IMHO, less noticeable compared to the days. In the following screenshots there are a few examples (the first on the left is from the patch), what do you think? There are different/better suggestions?
- the look must be verified on Linux where, usually, the font is a bit larger than Windows.


I've also fixed a wrong background color for the selected day when it is a day-off day (an error from the patch for bug 985114).

Here there are builds for Linux and Mac from the try server, Windows didn't work:
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/try-builds/bv1578@gmail.com-d975612dbf54/
Attachment #8625302 - Flags: review?(philipp)
Comment on attachment 8625302 [details] [diff] [review]
patch - v1

Review of attachment 8625302 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/base/content/calendar-month-view.xml
@@ +823,5 @@
> +              weekLabel.setAttribute("hidden", "true");
> +              // Take into account whether the days-off are displayed or not.
> +              if (weekLabelColumnPos < 0) {
> +                  if (this.mDisplayDaysOff ||
> +                      this.mDaysOffArray.indexOf((j + this.mWeekStartOffset) % 7) == -1) {

I think Array has a contains/includes function now.

::: calendar/locales/en-US/chrome/calendar/calendar.properties
@@ +469,5 @@
> +# the minimonth header.
> +# More than one letter can also be used but, generally, more than two causes
> +# the minimonth to enlarge horizontally.
> +#    %1$S will be replaced with the index of the week
> +initialOfWeek=W %1$S

abbreviationOfWeek sounds more correct
Attachment #8625302 - Flags: review?(philipp) → review+
Comment on attachment 8625303 [details]
different look for the minimonth

For the looks, I like the first (topleft) variant most. I think maybe it would make sense to include a (enabled by default) option in the prefs if week numbers should generally be shown or not. Personally, I don't care about week numbers at all, no one in my environment uses week numbers for planning, so I would disable this option. I didn't notice that the columns are less wide, so I think its ok.
Attachment #8625303 - Flags: ui-review?(richard.marti)
Comment on attachment 8625303 [details]
different look for the minimonth

I also like the topleft the most. The reduced cell width is not remarkable and okay.
Attachment #8625303 - Flags: ui-review?(richard.marti) → ui-review+
I would suggest to remove the column heading "W" completely to avoid localization issues that might affect the display e.g. due to long strings. At the moment we use "shortcalendarweek" from calendar.properties that is "CW" for EN-US, "Uge" for DA, or "Seachdain na bl." for "GD".

I agree that there should be a configuration switch to turn on and off this feature. If this switch is exposed in the configuration UI is another topic.
I'd actually suggest making this an exposed config option.
(In reply to Stefan Sitter from comment #27)
> I would suggest to remove the column heading "W" completely to avoid
> localization issues that might affect the display e.g. due to long strings.

Do you mean only in the minimonth, right?

(In reply to Philipp Kewisch [:Fallen] from comment #28)
> I'd actually suggest making this an exposed config option.

Unless we want to create another section in the "General" tab, the only suitable place seems in the General section of the "Views" tab, beside the "Start the week on:" preference.
(In reply to Decathlon from comment #29)
> (In reply to Philipp Kewisch [:Fallen] from comment #28)
> > I'd actually suggest making this an exposed config option.
> 
> Unless we want to create another section in the "General" tab, the only
> suitable place seems in the General section of the "Views" tab, beside the
> "Start the week on:" preference.

On in-content prefs it would be no problem to add a new section. But now the window pref is still the default and beside the "Start the week on:" is okay.
> > I would suggest to remove the column heading "W" completely to avoid
> > localization issues that might affect the display e.g. due to long strings.
> 
> Do you mean only in the minimonth, right?

I only looked at the minimonth image in Attachment 8625303 [details] but if there are other locations where the new calendar week abbreviation shows up my statement about potential l10n issues apply to those locations as well.
Attached image without week abbreviation β€”
There is a week abbreviation in month and multiweek views as you can see in the Attachment 8485517 [details] (the first image on the left).

I noticed that a few locales have a long "shortcalendarweek" string, for this reason I introduced another string with the recommendation, in the localization note, to use only the first letter or a maximum of two letters for room reasons.

I fear the missing abbreviation of "week" may cause misunderstandings with the day number in the views (instead the minimonth is less problematic). Maybe in this case we should use a lighter color as showed in this screenshot (a different background color only under the label doesn't seem a valid solution).
Attached patch patch-v2 - with preference (obsolete) β€” β€” Splinter Review
I've added a preference and corrected the issues in comment 24.

About the issues of the string in the label as Stefan mentioned in comment 27, I've done in this way:

I've completely removed the header in the minimonth where a long string could cause a big problem about the horizontal size (because of an "equalsize" attribute). For example the string "W" didn't cause any issue, instead the string "Week" caused the minimonth to enlarge of about a 35%.
In this way the look now is like the image in the bottom right corner of the attachment 8625303 [details] .

Instead I've not added any string or character in the en/US locale but I've left the possibility to localize the labels in the views (the localization note warns about possible risks of a long string). The look in the views is like the image on the right in attachment 8631252 [details] .
The alternative would be to add a character "W" like the previous patch or to make an hardcoded week number but I'm pretty sure there will be few locales that will require some kind of customization.
To prevent possible issues caused by a string too long, I've added an attribute crop="end" for the week label and removed the same attribute for the day label (it required the "overflow: hidden" style on the parent box to avoid overlapped labels when days-off are not displayed).

Let me know if you prefer a different solution.
Attachment #8625302 - Attachment is obsolete: true
Attachment #8636624 - Flags: review?(philipp)
Comment on attachment 8636624 [details] [diff] [review]
patch-v2 - with preference

Review of attachment 8636624 [details] [diff] [review]:
-----------------------------------------------------------------

I think this solution makes sense, good work :-) Just a few minor nits:

::: calendar/base/content/calendar-month-view.xml
@@ +526,5 @@
> +                   this.mShowWeekNumber = aSubject.getBoolPref(aPreference);
> +                   if (this.mShowWeekNumber)
> +                       this.refreshView();
> +                   else
> +                       this.hideWeekNumbers();

Please add brackets for the one-line ifs.

@@ +846,5 @@
> +                  let weekNumber = cal.getWeekInfoService().getWeekTitle(dt);
> +                  let weekString = cal.calGetString("calendar", "abbreviationOfWeek", [weekNumber]);
> +                  weekLabel.setAttribute("value", weekString);
> +                } else {
> +                  weekLabel.setAttribute("hidden", "true");

I think you can use weekLabe.value = weekString and weekLabel.hidden = true/false here.

@@ +914,5 @@
> +            let row = rows[i];
> +            for (let j = 0; j < row.childNodes.length; j++) {
> +              let daybox = row.childNodes[j];
> +              let weekLabel = document.getAnonymousElementByAttribute(daybox, "anonid", "week-label");
> +              weekLabel.setAttribute("hidden", "true");

Same here
Attachment #8636624 - Flags: review?(philipp) → review+
Hi Philipp,

I'd really like to try out the patch you've made for adding the calendar-weeks to the mini-month-view, since I'd dearly like to have them. :-)
It would be also a way to test them in a german-speaking context.

But since I have never done something like adding a patch like this before, I'm not sure how to go about it.
Can you give me a short how-to?

I'm using TB 38.1.0 on Windows 7 64bit Professional with the following Add-ons:
Allow HTML Temp	3.6.4	true
Calendar Tweaks	6.1	true
CuteButtons - Crystal SVG	0.3.8.1-signed	true
Display Mail User Agent	1.7.0	true
Get Selected Mails	0.10.0	true
Lightning	4.0.1.2	true
Manually Sort Folders	1.1	true
Mark All Read Button	0.7.1	true
MinimizeToTray revived (MinTrayR)	1.1.2.1-signed	true
Provider for Google Calendar	1.0.4	true
Quote Colors	0.3	true
Restart application	1.2.1.1-signed	true
Show Calendar Week	0.3	true
Signature Switch	1.6.13	true
Slim Add-ons Manager	10.1-signed	true
StartupMaster	1.6.1-signed	true
Timeline	0.5	true
Year View	0.4.5	true
Enigmail	1.8.2	false
Launchy	4.4.0.1-signed	false
Quote Highlight	1.07	false
Remove Duplicate Messages	0.1.14	false

Thanks
Kate
(In reply to Katharina Wolkwitz from comment #35)
> I'd really like to try out the patch you've made for adding the
> calendar-weeks to the mini-month-view, since I'd dearly like to have them.
Hi Kate. First of all, the credits must go to Decathlon. I only reviewed the patch :-)


> But since I have never done something like adding a patch like this before,
> I'm not sure how to go about it.
> Can you give me a short how-to?
The patch applies to the source code of Lightning and given there are string changes it is not trivial to apply it to the final package. What you would need to do is set up the developer environment, apply the patch, then build the final xpi. Alternatively, you could take apart the final xpi, map the filenames from the patch to those of the final xpi, apply the modified patch, make sure the locale changes are also applied to the de locale, then repackage the xpi and install it.

Given this process is a bit more complicated than just a few commands in the command line, it might be easier to wait for this patch to be checked in and then try a nightly build. On special request I can do the above steps and send you a modified version of Lightning 4.0.2 that has this patch applied.
(In reply to Philipp Kewisch [:Fallen] from comment #36)
> Given this process is a bit more complicated than just a few commands in the
> command line, it might be easier to wait for this patch to be checked in and
> then try a nightly build. On special request I can do the above steps and
> send you a modified version of Lightning 4.0.2 that has this patch applied.

Hi Philipp,

if you'd be so kind as to send me the modified version of Lightning 4.0.2, I'd gladly test it in my German language environment and post the results here.
The email-address to send it to is wolkwitz@fh-swf.de

Katharina
Attached patch patch - v3 β€” β€” Splinter Review
Patch with corrections requested in comment 34.
I've also adjusted a bit the css classes for the minimonth, now they are more similar to the classes of the days in the minimonth.
Attachment #8636624 - Attachment is obsolete: true
Attachment #8650420 - Flags: review+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 4.5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: