421304 - Today Pane: Show end time of event

Status: NEW

(Calendar :: Calendar Frontend, enhancement)

Description

[Robert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 ImageShackToolbar/4.4.3
Build Identifier: Thunderbird Version 2.0.0.12 (20080213); Lightning 0.8 (Build 2008030520)

In the agenda view, only the starting times of the events are shown. However, it would be quite useful to also show the ending time too. Otherwise you have to doubleclick on the event (and since one of my calendar is read-only and no times are shown in the "editing" dialog for these, it's even more complicated).

I will attach a patch which appends the end time in agenda view. It's my first patch, so I'd appreciate any feedback. It also includes a slight change to the display of the start date so now the day of start/end date is shown as follows:
- Start and end at the same day => only the times.
- Start at the displayed day, end one or more days later => time for start, date and time for end.
- Start before the displayed day => date and time for both. In the current version, it displays only the time of the start date, which is irritating because you'd expect that any times shown are for the displayed day.
- For the "soon" section, the start day is always shown.

The date format is the one selected in the options. This is not really perfect if you want long dates in tooltips, dialogs etc. but short dates in the agenda view. However, i tried to reuse the existing functions, including formatDateTime(). Using short dates in any case would be possible by calling formatShortDate() and formatTime(), but there is also that calendar.date.formatTimeBeforeDate setting which would have to be kept in mind.

Reproducible: Always

Steps to Reproduce:
Well, just look at the agenda.
Actual Results:  
Start time is shown for the events.

Expected Results:  
From the source code, it works as designed. However, I'd like to see end times there as well. And if it's a multiple day event, it should show the day of the start date.

Comment 1

[Robert]

Attachment: Proposed patch as described in the report

Comment 2

[Berend Cornelius]

When I implemented the agenda-listbox, we found that we should only provide the most necessary information and restricted ourselves to only display the starttime.

Comment 3

[Lars Wohlfahrt (thetux)]

For my personal workflow are this not enough informations. The endtime of events is absolutly needed for me. Now I need to edit the event to see the time or switch to calendar mode, but then I can't see my mails anymore... If the calendar is in read only mode, I can't even see the end time via edit: in this case there is just a small box with title and date.

So for me any patch regarding this issue is more than welcome! :-)

Comment 4

[Stefan Sitter [:ssitter]]

In my opinion end time is not necessary and would just take up valuable space. If this enhancement request is considered there should be a preference to turn of this behavior. Instead tooltips should be displayed for the agenda entries (Bug 330391)

In case of showing start and end time you probably want to use calIDateTimeFormatter:formatInterval. I think Bug 413103 is good start to add a formatInterval variants for short or long format.

Regarding the read-only event dialog see Bug 396819 / Bug 395017.

Comment 5

[Robert]

Thanks for your comments.
Tooltips and an event dialog would be good to have indeed. However, seeing the end time at first sight would be nice too in my opinion. I don't really understand your point about the space, that box at the top where you can select the date is far bigger than start time and end time together. Anyway, a preference to disable end times would be fine as well.

The reason why I didn't use formatInterval is that it always includes at least one date. Outputs like "13:00 - 17:00" and "13:00 - 7 Jan 2006 9:00" are missing. But thank you for your suggestion.

One question though: If you should decide not to use the patch, what's the easiest way for me or other interested users to patch my installation and keep these changes for newer versions as well?

Comment 6

[cmtalbert]

(In reply to comment #5)
> Thanks for your comments.
> Tooltips and an event dialog would be good to have indeed. However, seeing the
> end time at first sight would be nice too in my opinion. I don't really
> understand your point about the space, that box at the top where you can select
> the date is far bigger than start time and end time together. Anyway, a
> preference to disable end times would be fine as well.
> 
> The reason why I didn't use formatInterval is that it always includes at least
> one date. Outputs like "13:00 - 17:00" and "13:00 - 7 Jan 2006 9:00" are
> missing. But thank you for your suggestion.
> 
> One question though: If you should decide not to use the patch, what's the
> easiest way for me or other interested users to patch my installation and keep
> these changes for newer versions as well?
> 
The easiest way to do that would be to make this an extension.  (You can make an extension for Lightning).

Comment 7

[cmtalbert]

Comment on attachment 307728 [details] [diff] [review]
Proposed patch as described in the report

I'm withholding final review until we decide as a team on whether we want to take this into the final product or not.  If we do take it, it sounds like we'd need preference structures in here to turn off the display of the end date, and so I'd have to r- on the lack of those.  But, otherwise, the code looks pretty good, just one issue, below....

>Index: agenda-listbox.js
>===================================================================
>RCS file: /cvsroot/mozilla/calendar/lightning/content/agenda-listbox.js,v
>retrieving revision 1.5
>diff -u -8 -p -r1.5 agenda-listbox.js
>--- agenda-listbox.js	28 Feb 2008 15:49:20 -0000	1.5
>+++ agenda-listbox.js	6 Mar 2008 16:53:34 -0000
>@@ -225,17 +225,22 @@ function addItemBefore(aNewItem, aAgenda
>     // set the item at the richlistItem. When the duration of the period
>     // is bigger than 1 (day) the starttime of the item has to include
>     // information about the day of the item
>     if (aAgendaItem == null) {
>         this.agendaListboxControl.appendChild(newelement);
>     } else {
>         this.agendaListboxControl.insertBefore(newelement, aAgendaItem);
>     }
>-    newelement.setItem(aNewItem, (aPeriod.duration > 1));
>+    var periodStart = aPeriod.start.clone();
>+    periodStart.hour = periodStart.minute = periodStart.second = 0;
>+    periodStart.isDate = false;
>+    newelement.setItem(aNewItem,
>+                       (aPeriod.duration > 1 || aNewItem.startDate.compare(periodStart) < 0),
>+                       !sameDay(aNewItem.startDate, aNewItem.endDate));
This is sending three parameters into setItem and everywhere else we only send this two parameters.
Also, how does this handle the situation where your event starts and ends on two different days?  Does that cause the "agenda" to grow or shrink in some way?  How does it handle only day events?  It makes me a little nervous that right above here you set periodStart.isDate to false.  How do you know that the event you're working with is not a "date" versus a date with time information?

Comment 8

[cmtalbert]

Added to next week's calendar call agenda in hopes of driving some resolution and progress on the bug --- all interested are welcome to get on the call.

http://wiki.mozilla.org/Calendar:Status_Meetings:2008-03-26

Comment 9

[Pete Riley]

(In reply to comment #7)
> If we do take it, it sounds like we'd
> need preference structures in here to turn off the display of the end date,

Perhaps the preferences could be combined with those in bug 307892 and bug 328923.

Personally I would like to see the end *time* in the views and in the today pane but never the short or long date (except in tooltips).  Also, I would prefer to see the day of the week (Monday-Sunday) shown only once per day as discussed in bug 417222.

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 307728 [details] [diff] [review]
Proposed patch as described in the report

>Index: agenda-listbox.js
>+            var end =  calGetEndDate(item).getInTimezone(calendarDefaultTimezone());
>+            if (longFormatEnd) {
>+                duration = duration + " - " + dateFormatter.formatDateTime(end);
>+            } else {
>+                duration = duration + " - " + dateFormatter.formatTime(end);
>+            }

This is not the most localization-friendly way to format an interval (not all languages use a dash with spaced around it to seperate the two parts).
You should use calIDateTimeFormatter.formatInterval. Or, if that doesn't work for this case, that interface can be extended to do what is needed here.

Comment 11

[Stefan Sitter [:ssitter]]

See Bug 413103 for fixing the issue with formatInterval() and building the final string.

Comment 12

[Robert]

(In reply to comment #10)
> This is not the most localization-friendly way to format an interval (not all
> languages use a dash with spaced around it to seperate the two parts).
> You should use calIDateTimeFormatter.formatInterval. Or, if that doesn't work
> for this case, that interface can be extended to do what is needed here.
> 

You are right, we should keep that in mind. However, the localization issue should be discussed in the bug Stefan mentioned.
As stated above, formatInterval as it is right now doesn't offer some of the necessary formats. I think two additional, but optional parameters would be needed to hand over information about which format is needed for start and end date/time.

Comment 13

[Robert]

I'm afraid I can't take part in the meeting, so I'll try to explain my opinion more detailed here.

First, why I think not only start times should be shown: I'd like to see how long the next events last and how much time I have before the next one starts. Again, in the usual case (event ends the same day as it starts), the width of the label is less than the width of the description label, so this doesn't have any influence on the width of the complete item. In situations where one or two dates are shown additionally to the times, the text will be cut, just like the description would be.

You can find an explanation of the possible situations and the according format of start and end time/date at the top of the page. In reply to your comment, Pete, imagine a situation where your event starts at 16:00 the one day and ends 17:00 the next day. If I saw "16:00 - 17:00" in the today pane then, I'd interpret that as an one-hour-event, which is wrong of course. That's why I think the end date is necessary here. Of course, this would only be shown if start and end date differ.

Currently, the today pane one the second day (same situation) would even be more confusing. You see "16:00" then, although the event started the day before and might continue right in the morning of that day. For this reason, I think displaying the start *date* is necessary here as well. But when the start date is shown and the end of the event is not the same day, I think the end date should be shown as well (except for the "soon" section if both dates are the same). Let's say you look at the events for Tuesday and you see something like "Monday, 16:00 - 17:00". At first sight, this looks like "Start: Monday, 16:00; End: Monday, 17:00". However, as this should be for Tuesday, it might mean "End: Tuesday, 17:00". But it could also be "End: Wednesday, 17:00".

When you say that you "never" want to see an end date, does that include the "soon" section as well? If not, what about this idea: When you look at a list of events for one special day, the major reason is that you want to know what you have to do and when. Maybe you aren't interested in the day and time it starts if that's not the day you are looking at. Let's say we look at Tuesday again. If the event starts on Monday, you have to be at the event's location on Tuesday some time in the morning. If it continues on Wednesday, you will be busy on Tuesday until evening. If you know that, you know enough to make your plans for Tuesday, because you don't need to care if the event starts at 8 or 9 on Monday. So the idea would be: If the events starts before the day you look at, display something like "... - 17:00". If it ends the next day(s), it could be "16:00 - ...". And instead of "... - ...", this should be an allday event - simply because you are busy with the event all day, so for that day it *is* an allday event. Like this, the label is not much bigger than before as you will never see any dates, and overview isn't lost. Actually I'd prefer this to the way with full details.

Clint, you are right about the technical stuff. At that place, the object to work at could either be a "normal" event or an allday event. For the later one, nothing should change. Actually the second parameter doesn't have any effect as it isn't used anywhere in the implementation of the setItem method. For the normal events, I added the parameter "longFormatEnd" to agenda-listbox.xml, so three parameters are right for these. As allday events don't display any dates or times anyway, there should be an "if" so all those commands about displaying the start/end date are executed only for normal events. In that case, the event has always date and time, so isDate=false is correct. And if the second parameter isn't processed anyway for allday events, shouldn't it be removed? It's called "period", but currently it's filled with a boolean value of completly different meaning.

Anyways, is the setItem method of "agenda-richlist-item" used anywhere else than in that function? If you should decide that something like my new idea should be realized, boolean is not enough to hand over information whether the start/end of the event should be shown as time, as three dots or as date and time (for the "soon" section).

Comment 14

[Pete Riley]

Robert, I agree with the points you made.  I like your idea to use an indicator for multiday events instead of using the start/end dates.  It's the same solution that was discussed (a lot!) in bug 199732 and resulted in Christian's UI proposal at http://wiki.mozilla.org/Calendar:Crossing_Day_Boundaries.

Also, I would guess that the today pane is narrow on most people's screens and another potential problem of using start/end dates instead of indicators is that there wouldn't be enough width to show everything on smaller screens and those people would have to show the tooltip anyway.

Comment 15

[Pete Riley]

p.s. I think the indicators would be nice in all three sections, not just the Soon section.

Comment 16

[Robert]

Actually I thought that the indicators should be shown only for single date sections since I didn't have any idea how to make clear on which of the five days in the "soon" section the event occurs. But ok, there are some possible situations where indicators would make sense also in the "soon" section (all of these are for multiday events).
1) start is before "soon" period, end is in the period => indicator for start, show end date+time
2) start is in period, end is after period => show full start date+time, indicator for end
3) maybe if start and end are in the period, but different days => same as for 2) => saves space at the cost of details. should be ok though since the today pane is not for making complicated plans for the future
4) start is before period and end is after period => could be shown as an allday event (rather "allperiod event" here)
In other situation I think displaying the start date is necessary, and I wouldn't replace an end time (without date) with an indicator because a time is already quite short.

Comment 17

[Daniel Boelzle [:dbo]]

Christian, could you please comment whether this is wanted from a UX point of view; thanks.

Comment 18

[Martin Schröder [:mschroeder]]

Comment on attachment 307728 [details] [diff] [review]
Proposed patch as described in the report

Shifting review. Don't know if this patch is up-to-date and wanted?

Comment 19

[Robert]

Comment on attachment 307728 [details] [diff] [review]
Proposed patch as described in the report

No, review of this patch is no longer needed here as there are new ideas in the last few comments. As Daniel said, Christian's comment on these is still needed to continue.

Comment 20

[raths]

I have lightning 0.9 and when the mouse is on the event I see the time of start and time of end and it works for the diary who is read-only

Comment 21

[Martin Schröder [:mschroeder]]

Confirming for now, but also setting uiwanted.