543712 - In Sunbird with multiple calendars: read-only events are RARELY visually associated with their calendars. Usually, the WRONG calendar is highlighted.

Status: RESOLVED INVALID

(Calendar :: Calendar Frontend, defect)

Description

[Graham Perrin]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-gb) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091211 Sunbird/1.0b1

Sunbird displays no relationship between an event and its calendar. 

This makes the software highly unsuitable for any use case where the relationship must be known.

Example (screen shots to follow): a Sunbird view of room bookings, where there is one calendar per room. 

The viewer can not see the room that is chosen for the event!

Reproducible: Always

Steps to Reproduce:
 1. subscribe to more than one read-only webcal URL served by Chandler Hub

 2. enable (check) all collections (calendars) 

 3. focus on a day or week in which: (a) one of the collections has _no_ events AND (b) at least one of the other collections has an event

 4. select (single click) the collection that has no events

 5. hover over any event during the period on which you are focused, or click that event, or double-click that event.
Actual Results:  
Sunbird continues to highlight the selected calendar, implying that the event is in that calendar. 

(It is not! The event is in a different calendar!)

Expected Results:  
Sunbird must display the calendar (collection) with which the event is associated. 

You should see the problem if you subscribe your Sunbird to at least the following URLs  —

webcal://hub.chandlerproject.org/webcal/collection/86d17970-ea4d-11de-86e7-ad6bd9dcb7da?ticket=24c5f780
(for room F13)

webcal://hub.chandlerproject.org/webcal/collection/64e087b0-01e1-11df-a5b2-cd9d60a5d616?ticket=eb3b1a40
(for rooms G24/25)

— then enable (check) both calendars, select G24/25 and focus on 16 April 2010.

Comment 1

[Graham Perrin]

Attachment: Sunbird suggests that the event is in rooms G24/25

Comment 2

[Graham Perrin]

Attachment: Chandler Hub proves that Sunbird fails to show the relationship with (the calendar for) room F13

Comment 3

[Graham Perrin]

Attachment: An event, opened: Sunbird continues to highlight the wrong calendar, fails to mention (or display in sidebar) the true calendar

Comment 4

[Graham Perrin]

In Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 the bug is not reproduced. 

Preliminary conclusion: the bug is limited to Sunbird. 

Quoting from discussion in <irc://irc.mozilla.org/#calendar>: 

> colours are not the solution … but thanks

> with only a minority of (calendars for) rooms configured in Sunbird, it becomes impossible to recognise a calendar from colour alone

> hovering must state the calendar (collection) of the event
> (I would normally say 'should' but for our use case, this is critical)

> selecting (single-clicking) the event should cause the sidebar of Sunbird to scroll to reveal the related calendar

> debatably, selecting the event should cause the sidebar of Sunbird to somehow highlight the related calendar

> opening (double-clicking) the event MUST state its calendar

Comment 5

[Graham Perrin]

Testing with a read-only subscription to 
http://www.mozilla.org/projects/calendar/caldata/BelgianFrenchHolidays.ics
proves that the bug is not limited to publications from Chandler Hub (instance of Cosmo).

Comment 6

[Graham Perrin]

Let's treat this bug as Sunbird only. 

Nearby, Lightning only, bug 543724 is 

> for a selected read-only event, 
> Lightning usually highlights the WRONG calendar (fails to display the true calendar)

(I'd describe both bugs as major or critical. Yes, the user of Lightning may double-click the event, but why would they double click an event to discover its calendar, if Lightning has already highlighted a calendar?)

Comment 7

[Graham Perrin]

(In reply to comment #4)
>> colours are not the solution … but thanks

Definitely, not a solution. I experimented a few days ago with just some (not all) of the calendars that we're asking viewers to read alongside each other (for room booking purposes). 

The palette must be limited — we can't expect viewers to distinguish between light, mid and dark. Distinguishing between just two shades (light and dark) is reasonably easy, but three or more shades of a single colour brings uncertainty. 

Moreover, the palette must exclude oranges and yellows; an event that is any colour becomes yellowish, orangey when selected (screen shot to follow). Such changes of colours makes relying on colour alone an unsuitable workaround. 

Also, accessibility: don't forget colour blindness.

Comment 8

[Graham Perrin]

Attachment: Colour-coding: Sunbird clearly tells us "green" for an event that is sometimes dark purple, sometimes yellowish. Way too confusing.

Comment 9

[Graham Perrin]

> NEVER visually associated with their calendars

More accurately, the true calendar might be highlighted — but only if by coincidence the user has selected that calendar before selecting the event. 

With three or more calendars: the likelihood is that the reader (viewer) of a collection of events will not consciously select a calendar before focusing on a read-only view of an event. 

(Put another way, we can't expect users to have psychic knowledge of event detail ;)

Comment 10

[Graham Perrin]

Attachment: A zip of a Sunbird profile that you can use to see the confusion

Comment 12

[Simon Paquet [:sipaq]]

I'm not at all convinced that this is a bug.

First of all, there are numerous ways to clearly identify the calendar to which an event belongs:

- calendar colour (if chosen)
- event category (if assigned)
- event location
- event description

At least one or a combination of those four should give you a hint to which calendar an event belongs.

That being said, there are two potential bugs here, that should be addressed:

1. When you select an event, we should automatically select the calendar to 
   which this event belongs.
2. We should think about adding the Calendar name to the mouseover tooltip 
   that is shown when you hover over an event with your mouse.

I filed bug 543742 and bug 543744 for this. This bug in its current state is already pretty convoluted and not useful for a developer who would like to fix this.

Comment 13

[Graham Perrin]

(In reply to comment #12)

Thanks for the speedy translation of this issue!

Without re-opening, some responses: 

> - event category (if assigned)

Not possible when the client software that creates or edit the events does not (can not) use categories. (We use CalDAV clients to create/edit — typically iCal or Chandler Desktop; and Sunbird was the likeliest candidate for users whose role is to view (not edit) those events, as a room booking system.)

> - calendar colour (if chosen)

With only a few calendars, in practice we reached the limits of colour as a useful method of identification. If you experiment with the profile provided, you'll see that we had to leave a few of the calendars grey — as a sacrifice, so that colour could be useful for the other calendars.

> - event location

True, but I find that few people use that field. Also, some people misunderstand its purpose (e.g. they enter a web location, not a geographic location). In any case: we shouldn't force use of the location field. 

> - event description

In our use case, the description never offers a hint — CalDAV service with clearly labelled calendars, one per room, a room booking system, so that porters and other people who service the building should be able to see what's going on in the building and tell (from the name of the calendar, e.g. room G22) that a selected event requires that room. 

I'll attach a screen shot to demonstrate. 

>> debatably, selecting the event should cause the sidebar of Sunbird to 
>> somehow highlight the related calendar

> 1. When you select an event, we should automatically select the calendar to 
>    which this event belongs.

Bug 543742 is *ideal* — thanks! That's my preferred solution but I didn't know whether it's appropriate here. 

(Some systems are designed to specifically *not* alter what's in the sidebar based upon a selection elsewhere. I don't know Sunbird well enough to guess whether there's a use case that would require that.)

Comment 14

[Graham Perrin]

(In reply to comment #13)

> (Some systems are designed to specifically *not* alter what's in the sidebar
> based upon a selection elsewhere. 

Ah, there's a use case at <https://bugzilla.mozilla.org/show_bug.cgi?id=543742#c1>.

Comment 15

[Graham Perrin]

Attachment: > In our use case, the description never offers a hint …

Comment 16

[Graham Perrin]

Attachment: > In our use case, the description never offers a hint …