Updated calendar views

VERIFIED FIXED in 0.9

Status

Calendar
Calendar Views
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: clarkbw, Assigned: Berend Cornelius)

Tracking

unspecified
Dependency tree / graph
Bug Flags:
blocking-calendar0.9 -
wanted-calendar0.9 +

Details

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 317158 [details] [diff] [review]
css and xml patch

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

Comment 1

10 years ago
Created attachment 317159 [details]
month view screenshot of patch working

Comment 2

10 years ago
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.

Comment 4

10 years ago
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

Comment 5

10 years ago
(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
(Reporter)

Comment 6

10 years ago
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.

Updated

10 years ago
Assignee: nobody → clarkbw
Status: ASSIGNED → NEW

Updated

10 years ago
Status: NEW → ASSIGNED

Comment 7

10 years ago
(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.

Comment 10

10 years ago
> 
> 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.

Comment 11

10 years ago
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.

Comment 13

10 years ago
(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 )
(Reporter)

Comment 14

10 years ago
(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
Created attachment 319198 [details] [diff] [review]
Proof of concept for further view simplification

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.

Comment 19

10 years ago
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.

Comment 20

10 years ago
Created attachment 320979 [details]
screenshot of the patch with "1px borders on flex bug"

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.

Comment 21

10 years ago
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.
(Reporter)

Comment 22

10 years ago
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.

Updated

10 years ago
Blocks: 434019

Comment 23

10 years ago
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 ..)

Comment 24

10 years ago
Created attachment 322549 [details]
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!

Comment 25

10 years ago
Definitely prefer your mock-up to the situation at present. They're aesthetically very pleasing and convey the information well.

Comment 26

10 years ago
Created attachment 322976 [details]
Updated Interface Proposal Mock-Up

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

Comment 27

10 years ago
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.

Updated

10 years ago
Flags: blocking-calendar0.9?

Updated

10 years ago
Flags: blocking-calendar0.9? → blocking-calendar0.9-
(Assignee)

Comment 29

10 years ago
Created attachment 331059 [details] [diff] [review]
calendar-views-patch

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

Comment 30

10 years ago
Created attachment 331060 [details]
zip-file with images for the new calendar-views

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.

Comment 31

10 years ago
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

Updated

10 years ago
Attachment #331059 - Flags: ui-review?(christian.jansen) → ui-review+
(Assignee)

Comment 32

10 years ago
Created attachment 331076 [details] [diff] [review]
calendar-views-patch v. #2

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+
(Assignee)

Comment 34

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Blocks: 447800
(Assignee)

Comment 35

10 years ago
I set up Bug 447800 – month View is missing a right border as a follow-up bug
Target Milestone: --- → 0.9

Comment 36

10 years ago
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

Comment 37

10 years ago
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 → ---
(Assignee)

Comment 38

10 years ago
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
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 39

10 years ago
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.

Comment 40

10 years ago
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! :)

Comment 41

10 years ago
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.

Comment 43

10 years ago
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?

Comment 44

10 years ago
Someone opened bug 450034 for that.  I agree with you.

Comment 45

10 years ago
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.