Closed Bug 430382 Opened 12 years ago Closed 12 years ago

Updated calendar views

Categories

(Calendar :: Calendar Views, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: clarkbw, Assigned: berend.cornelius09)

References

Details

Attachments

(8 files, 1 obsolete file)

hey, I did this hack up just yesterday.  It probably needs some work to get out all the kinks.  Most of this still needs to be fit in with Christians mockups where it makes sense, http://wiki.mozilla.org/Image:Calendar-view-w-tasks.png  We have a slightly different visual style that should be merged.

My patch should only affect the month and weekly views, the other views in my opinion should have a bit more 3D effect compared to the month view which should be flat and open.

Basic premise was to flatten out the month view and bring the focus only to the events.  I cleared out a lot of the extra background colors such that nothing is distracting; the visual effect should give hot spots to areas where you're busy and cold spots to areas you're free.

I'll attach a screenshot as well.
From my point of view we should integrate this patch. Fine tuning should be done in spin-off bugs.
Status: NEW → ASSIGNED
Flags: wanted-calendar0.9?
From the attached screenshot I'm not able to distinguish what are the workweek days? What are the non-workweek days? What is the current day? What is the currently selected day? In my opinion this information should be visible.
Bryan, one thing I noted is the use of hardcoded colors in your patch. I see a lot of #FFFFFF and #000000 and different shades of grey here, which could probably be switched over to system colors as shown here:

http://www.iangraham.org/books/xhtml1/appd/update-23feb2000.html

That would also improve our accessibility and system integration story.
OS: Linux → All
Hardware: PC → All
(In reply to comment #1)

I think it's too loud -- IMO only all-day events should have a background color.  Please see "Thursday" and "Friday" at
http://wiki.mozilla.org/Calendar:Improved_Events_and_Tasks
sorry, back online again.

(In reply to comment #3)
> From the attached screenshot I'm not able to distinguish what are the workweek
> days? What are the non-workweek days? What is the current day? What is the
> currently selected day? In my opinion this information should be visible.

Yes, I removed the coloring for workweek, non-workweek days.  The current day should be visible and shaded with a yellow cream like color (before it was a blue).  The selected day is a much lighter highlight than before; this might need to be darkened.

I believe the goal of this view is to give a heat map view of what days a person is available.  And I think most people easily know what days are non-work days without looking at the calendar :) so shading that seemed to just create a visual noise that distracted from the goal of seeing what days you're busy and what days you aren't.

(In reply to comment #4)
> Bryan, one thing I noted is the use of hardcoded colors in your patch. I see a
> lot of #FFFFFF and #000000 and different shades of grey here, which could
> probably be switched over to system colors as shown here:
> 
> http://www.iangraham.org/books/xhtml1/appd/update-23feb2000.html
> 
> That would also improve our accessibility and system integration story.

Yeah that's possible, I didn't see those being used before.  I wonder if it will be helpful in many places though.  For standard elements like buttons and menus I can see that the system colors are predefined, however for something like a calendar month-day border I would just be choosing one of the border colors from the system list.  Perhaps GrayText makes sense for the date numbers.


(In reply to comment #5)
> I think it's too loud -- IMO only all-day events should have a background
> color.  Please see "Thursday" and "Friday" at
> http://wiki.mozilla.org/Calendar:Improved_Events_and_Tasks

Right, I wasn't able to fix that piece with just CSS.  I believe there needs to be more work done on the event processing such that different types of events( all day, timed events ) are processed differently.  Currently the code treats them the same.  But this is really important to be fixed, is there a current bug for this problem?  With a little bit of extra work by someone who knows that code better it could easily be solved such that it's only a CSS problem afterward.
Assignee: nobody → clarkbw
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
(In reply to comment #6)
> And I think most people easily know what days are
> non-work days without looking at the calendar :) 
IMHO  that's not completely true, because in other country (like mine : France) the Sunday are the last day of the week and will be right end. So for me looking at your screenshot don't tell me that your first column is a day-off until I read the header.

In your screenshot, we can see a selected day in the mini-month, IMHO the selected day in the view should have the same style because today I always found very disturbing in lightning that not to know if the cell marked with a background color is the current day or the selected day, and so I use a lot the button "Today" to be sure.

For me being able to see in a snap what is the current month is important.because I use also lightning to schedule a meeting and to know where a month start and where it's finished a very very important for me. Ex : I need to make an appointment in june, so I'm looking for june with no day-off.

To conclude I like a lot the grey header, the thin border. but unfortunately I agree with comment #3, the lack of information would make me prefer the previous style than yours :-/ 

These points are only there to help you in making better style and give my user feeling. 
Maxime: but if it's your calendar, wouldn't you know whether you've configured it to start on sunday, monday, or whenever?
One alternative thought is to indicate work/weekend in the columns, as opposed to each day.
> 
> I believe the goal of this view is to give a heat map view of what days a
> person is available.  And I think most people easily know what days are
> non-work days without looking at the calendar :) so shading that seemed to just
> create a visual noise that distracted from the goal of seeing what days you're
> busy and what days you aren't.
> 

I agree with comment #7 exactly because of what you said "the goal of this view is to give a heat map view of what days a person is available." so, since I doesn't consider myself available for work on non-work day I want it to appear busy, the shading tell me that, it's more distrating to look at the top just to be certain of witch day it is. and no I never sure about where is the non work day because my calendar use to change by itself some time... I didn't understand why nor if it's still doing it with .8 but the shading assure me that I know witch day I'm.
in (In reply to comment #8)
> Maxime: but if it's your calendar, wouldn't you know whether you've configured
> it to start on sunday, monday, or whenever?
I would like to say yes, but I will answer no because sometime I hide/show show week-end. And so the view change, so my visual memory can't be used.
So I totally agree with comment #10
> the shading assure me that I know witch day I'm.
From the attached patch I see that the alarm icon was removed too. This icon was added upon users request and therefore should stay I'd say. Currently it can be switched off globally by setting the preference calendar.alarms.indicator.show to false. Maybe there should be a separate preference for day/week (default enabled) and multiweek/month (default disabled) to allow users to return back to the current state?

(In reply to comment #7)
I agree that in Month View the start and end of the month should be easily noticeable. For users that don't need this we offer the Multiweek View.

+1 for removing the drop shadows for better readability and gaining space.
(In reply to comment #12)
> From the attached patch I see that the alarm icon was removed too. This icon
> was added upon users request and therefore should stay I'd say. Currently it
> can be switched off globally by setting the preference
> calendar.alarms.indicator.show to false. Maybe there should be a separate
> preference for day/week (default enabled) and multiweek/month (default
> disabled) to allow users to return back to the current state?

we actually have a bug about that alarm icon option, probably talk about it there ( bug 416482 )
(In reply to comment #12)
> From the attached patch I see that the alarm icon was removed too. This icon
> was added upon users request and therefore should stay I'd say. Currently it
> can be switched off globally by setting the preference
> calendar.alarms.indicator.show to false. Maybe there should be a separate
> preference for day/week (default enabled) and multiweek/month (default
> disabled) to allow users to return back to the current state?

Yes, we might need a replacement for that; I'm not certain it's needed at this view but at least if it were subtle it could work.  The current alarm bell is much too visually disturbing, it draws your eyes directly to it even though it is ancillary information. (i.e. You don't scan your month view for items that don't have an alarm)

Also it won't work well unless there is always a background color available; something that will hopefully be fixed for timed events.

If we do have an alarm I think we should go with something simple and flat like the rest of the month view.  It should use the same color as the font and sit at the end of the event.  (a currency symbol is just for an example)
  8:30 Event with an Alarm... ¤
  8:30 Event with out an A...
Duplicate of this bug: 426979
Carrying over wanted-calendar0.9 from duplicated bug.
Flags: wanted-calendar0.9? → wanted-calendar0.9+
Summary: updated month and multiweek view → Updated calendar views
IMO we can be a little bit more aggressive in calendar-month-view.xml and simplify our code even more. I've attached a proof-of-concept patch just for calendar-month-view.xml.

This might even improve the view performance, since it would simplify our view structure and the corresponding DOM.
See also Bug 391187 regarding modifications to the event box display.
Bryan, I think that you can now distinguish between all-day events and non-all-day events if you use the css enhancements that Philipp added in bug 202360.

FWIW, I think that the gradient and shading for some all-day events (e.g. holidays) in month view looks really nice and prefer it over the "flat" look.
The patch presents the same problem that normally have Lightning and Sunbird: grid lines in calendar view are 2px thick but on window resize, sometime become 1px thick.
With lines 1px thick sometime lines disappear from the view.
I tried patch 317158 with the last Nightly Build and I like a lot new look, I hope this will be integrated soon, but I have to say that calendar grid with lines 1px thick  has the problem that some lines disapper from the view when you resize caledar view (with Thunderbird's main window, left pane, today pane) or when select a month with different number of weeks, like showed in the attachment 320979 [details]
https://bugzilla.mozilla.org/show_bug.cgi?id=430382

This behavior depends on a (supposed) bug described on  mozilla.dev.apps.calendar thread: "1px borders on flex bug ?"

http://groups.google.it/group/mozilla.dev.apps.calendar/browse_thread/thread/59d8b9a5f0f0e076/65dfb39fc3e9287a?hl=it#65dfb39fc3e9287a

As I posted there, now I'm using a workaround (personal and not "certified") made possible by changes in calendar-month-view.xml file due to fixed bug 322979. The following CSS code allows a grid in month view with lines 1px thick that "resist" to resizing (although 1px space is lost in calendar-month-day-box):

calendar-month-day-box { 	
	padding-right: 1px !important;
	padding-bottom: 1px !important;
	border: none  !important;
	border-left: 1px solid #3F7D91 !important;
	border-bottom: 1px solid #3F7D91 !important;
}
.calendar-month-view-grid-row{
	border-right: 1px solid #3F7D91!important;
}
calendar-month-view-column-header {
	border-bottom: 1px solid  #3F7D91!important;
}

in particular two lines with padding properties are fundamental.
It works with nightly builds after 2008-05-07, I also tried this workaround with patch 317158 but it doesn't work because calendar-month-view.xml is different.

I hope this could help to fix this problem because new look is very attractive and would be great to see it before Lightning 0.9 comes out.
Pete:  Awesome!  I haven't been able to get a recent lightning working since my TB upgraded to 3.0a2pre.  I'll try an updated patch when I'm back in working order again.

I think as a coloring option gradients and shading could be a cool way to distinguish certain calendars from others; that flat view would only be by default.
Blocks: 434019
1. I would consider maybe blocking bug 312830 (though that is more on a specific case, it is part of views .. )or other relation to that. ?

2. May have a relation to bug 322979, bug 391281, bug 432701 (same as above)

3. I filed a new bug 434019 on flex 1 borders issue. 
It was presented in ng and staid there while a more appropriate tracking would have been in a bug. I separate that from this discussion and making dependent on this one, as that is a specific issue that may be solved otherwise and this is a more active bug. But I'm not sure if that is the correct relation..

(I dropped there all comments from ng with their respective posters and the c from decathlon. Some core bugs may be related ..)
Attached image Day View Mock-Up
What do you guys think of this simple day view mock-up? It was designed to be a lot easier on the eyes than the current style!
Definitely prefer your mock-up to the situation at present. They're aesthetically very pleasing and convey the information well.
Thanks Jonathan, I have updated my mock-up for the calendar view which shows how hovering over an event could look, half hours and lighter out of work hour digits.
Matt, awesome work!  Should we create a new bug for the day view?

Something I'd like to run by you that I've been thinking about is showing a small sliver of the previous and next day on the left and right side of the day view. 

The idea is that you have more than enough horizontal space in the day view to display all daily calendar events.  So we could take a little bit of space on each side of the day view to show at least a marker for getting to the next or previous day.  (possibly similar to the wii and how it offers more space for moving left or right in their application view) I think there's lots of room to experiment with methods or ways to show the number of calendar appointments.

Here's an example:
+-+--------+-+
|1|    2   |3|
+-+--------+-+

{1} is the previous day
{2} is the current day
{3} is the next day

Calendar appointments for each day don't have to be shown, but at least a way to access the next or previous day. 
Bryan: ooh, I like that idea.  I've always though that a view of "yesterday through the day after tomorrow" would be a fine thing too.
Flags: blocking-calendar0.9?
Flags: blocking-calendar0.9? → blocking-calendar0.9-
Attached patch calendar-views-patch (obsolete) — Splinter Review
Christian gave me a css file that I consolidated a bit and where I adapted the implementation at some points.
Assignee: clarkbw → Berend.Cornelius
Attachment #331059 - Flags: ui-review?(christian.jansen)
Attachment #331059 - Flags: review?(philipp)
the new calendar contain new grip bars and new background-gradients. The shadow images were abandoned and are only denoted by a one pixel border.
This patch takes care about most of the comments above. The accessibility issues are valid, but I suggest to fix these in a spin-off bug.

Berend please remove the "calendar-day-label-back-vertical.png" it causes to much trouble. It should be replaced by a simple white background.

Please also add the following to the css. This code is bases on Decathlons flex fix.


/* Month View */
calendar-month-view {
  background-color: #FFFFFF;
}

.calendar-month-view-grid-column {
  min-width: 1px;
  width: 1px;
}

.calendar-month-view-grid-row {
  border-right: 1px solid #D2D2D2 !important;
}

calendar-month-day-box { 
  padding-right: 1px !important;
  padding-bottom: 1px !important;
  border: none  !important;
  border-left: 1px solid #D2D2D2 !important;
  border-bottom: 1px solid #D2D2D2 !important;  
}

ui=christian
Attachment #331059 - Flags: ui-review?(christian.jansen) → ui-review+
I worked in the comments of Christian. Andreas tested the patch and I increased the column-header boxes after his objection.
@philipp: I left an open "construction site within the binding "calendar-day-label", property "shortWeekNames". Within the 0.9 release cycle we somewhen lost the ability to adjust the weeknames (short-or longWeekNames) to the available width of the columns at the event "onoverflow". I'd like to deal with this in a later bug. Note: This has been corrupted *before* this patch.
Attachment #331059 - Attachment is obsolete: true
Attachment #331076 - Flags: review?(philipp)
Attachment #331059 - Flags: review?(philipp)
Comment on attachment 331076 [details] [diff] [review]
calendar-views-patch v. #2

>               box.setAttribute("orient", orient);
>-
>+              
This change adds spaces

>-          if (labeldayboxkids[0].boxObject.width * this.daysInView > this.mLongWeekdayTotalPixels) {
>+/*          if (labeldayboxkids[0].boxObject.width * this.daysInView > this.mLongWeekdayTotalPixels) {
>             // We have an underflow. Since the boxes all have equal width, we
>             // can use the first boxes' width and multiply bu the number of
>             // days in the view.
>             for (var i = 0; i < labeldayboxkids.length; i++) {
>               labeldayboxkids[i].shortWeekNames = false;
>             }
>           } else {
>             // We have an overflow
>             for (var i = 0; i < labeldayboxkids.length; i++) {
>               labeldayboxkids[i].shortWeekNames = true;
>             }
>-          }
>+          } */
Why commented out? Either remove, or if you have a good reason to keep the code, add a comment.

>+        if (aFilterAttribute == null) {
>+            setElementValue(element, aValue, aAttribute);            
>+        } else {}
Else not needed


r=philipp
Attachment #331076 - Flags: review?(philipp) → review+
I checked in the patch #2 on trunk and MOZILLA_1_8_BRANCH.
I also removed trailing whitespaces which blew up the patch a bit more.
I gave myself the freedom to add a little belated change to the css files:
There was a little misalignment between the headers and the grid in the month-view. I had to remove the right border of the grid and it was better. Adding a border to the header line confronted me with the disappearing lines that I could not even make appear again - even not with Decathlon's proposed solution in comment #21.
As I talked with Christian beforehand I know that he finds a missing right border on the grid "bad but tolerable". I will file a follow-up bug for this.

Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 447800
I set up Bug 447800 – month View is missing a right border as a follow-up bug
Target Milestone: --- → 0.9
that border is the issue on Bug 434019, and was right and bottom IIRC.
That I filed and after some talk eventually wfm. It's actually wfm on TB3 trunk, where the engine is different.

FWIW:  I'd briefly say that rendering of multiple nested flex1 results in that approximation, where in newer trunk it is more tolerant, allows more subdivision. 
(+IMHO, tolerable it is, but the superficial impression may be that the app is not so ok, matter of user trust ..)

hope helps
I checked this issue with the nightly build 2008072420. The week view shows now 8 days!

My xpi (commment 32) with patch 331059 shows 'only' 7 days. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
In reply to comment #37: This is a regression of
Bug 446366 – "Header of multiweek view always assumes the week to begin with Sunday, no matter what the actual setting is" and therefor I will reopen that bug and set back resolution of this issue.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
After this patch the month view is missing the last days of the current month. For July 2008 the last day would be the 27th. It seems that there is missing one row. Before the patch there were 5 rows and now there are only 4 rows.
I can both confirm Comment #39 and Comment #37. The multiweek and the day view seem OK though.

Still, very good work on that patch!!! The updated view looks so much better! :)
FWIW, the patch is working fine for me, so I guess the bugs in comments 37 and 39 are localization problems (I'm using the U.S.-English version).
For your information: The issues from Comment #37 and Comment #39 are regressions from Bug 446366. The issues from Comment #37 ought to be fixed by the follow up patch posted in Bug 446366 Comment #11. The issues from Comment #39 is filed as Bug 447996.
I still find it quite confusing that in month view the weekend-days are shaded in the same color as the days that are out of the current month. Shouldn't there be a difference?
Someone opened bug 450034 for that.  I agree with you.
Checked in lightning 2008081218 and Sunbird 20080812 -> VERIFIED. Because all open bugs (see comment #42) are filed and fixed/verified or a patch is available. 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.