no visual status mark on tentative or cancelled events/tasks

RESOLVED FIXED in 1.0b4

Status

--
enhancement
RESOLVED FIXED
14 years ago
8 years ago

People

(Reporter: desmor, Assigned: merike)

Tracking

unspecified
1.0b4
Bug Flags:
blocking-calendar1.0 +

Details

(Whiteboard: [not needed beta][no l10n impact])

Attachments

(3 attachments, 6 obsolete attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: MMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041112 Mozilla Sunbird/0.2b

Currently, marking events or tasks as 'Cancelled' or 'Tentative' (as
applicable), does not create any visual marker.  It would be better if there
where some sort of  marking (similar to the line for cancelled events), so that
inputing this information was actually useful. 

Reproducible: Always
Steps to Reproduce:
1. Create a task/event
2. Mark it as cancelled

Actual Results:  
Visually, nothing.

Expected Results:  
Some sort of marking.

Updated

13 years ago
QA Contact: gurganbl → sunbird

Comment 1

13 years ago
In addition to this, it would be helpful to have some type of indicator for events that are private vs. public (or confidential, in the .3 release). Maybe in the same way that there is a star for an all day event?

Comment 2

13 years ago
Does anyone know whether (and how) the status can be accessed via CSS (as the categories)?

Cheers,
Dominik

Comment 3

13 years ago
(In reply to comment #2)
> Does anyone know whether (and how) the status can be accessed via CSS (as the
> categories)?

It's not possible at the moment, but it would be pretty trivial to implement.

Comment 4

13 years ago
*** Bug 334051 has been marked as a duplicate of this bug. ***

Comment 5

13 years ago
*** Bug 298083 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 219437 [details] [diff] [review]
make them translucent

Simple patch to make tentative and cancelled items translucent. I think it looks not to bad, at least for tentative. I'm not sure if it is ok for cancelled.
(I might need to copy the stylerules to a numbor of other themes, but I'd like some feedback on the idea first)
Attachment #219437 - Flags: first-review?(jminta)

Comment 8

13 years ago
Comment on attachment 219437 [details] [diff] [review]
make them translucent

My original concern was that there are already OPAQUE and TRANSPARENT properties that the rfc specifies, but I was persuaded that those names don't really correspond to a best implementation.  So, I'm ok with the proposal, as long as we handle inline editing properly, since trying in a mostly-transparent area could be difficult.  We may want to get some feedback from some a11y folks too, for those with weak vision.
(In reply to comment #8)
> We may want to get some feedback from some a11y folks

Agreed. When we land this, it should have a pref to turn it off and use an icon or something rather than the opacity.

FWIW: Oracle Calendar uses a tiny check mark icon when all attendees have confirmed and accepted a meeting, and a question mark when there are still outstanding requests. Then they use colors to signify accepted (green), proposed but haven't accepted or rejected (blue), and red for rejected.

It's been so long since I've seen Outlook that I don't remember how they denote this stuff.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody

Comment 11

12 years ago
Comment on attachment 219437 [details] [diff] [review]
make them translucent

+          this.setAttribute("item-status", item.status);
Can we put this in an if (item.status) block, so we don't add unnecessary, empty css-selectors?

Index: base/themes/winstripe/calendar-views.css
===================================================================
RCS file: /cvsroot/mozilla/calendar/base/themes/winstripe/calendar-views.css,v

You probably also want pinstripe changes, no?  This likely wants a real UI-review, too. r=jminta for the code, however.
Attachment #219437 - Flags: first-review?(jminta) → first-review+
Comment on attachment 219450 [details]
screenshot

Requesting ui-review per comment#11.
Attachment #219450 - Flags: ui-review?(christian.jansen)
Component: Sunbird Only → Calendar Views
QA Contact: sunbird → views

Comment 13

11 years ago
Comment on attachment 219450 [details]
screenshot

Thank you for the patch. I really like to see something into that direction (visual differentiation between tentative, confirmed and canceled events), but I think the proposed visualization does not meet users expectations. IMO we should make use of an icon to display the state. The icon should be located next to the Alarm icon.
Attachment #219450 - Flags: ui-review?(christian.jansen) → ui-review-

Updated

10 years ago
Duplicate of this bug: 416518

Updated

10 years ago
Summary: no visual mark on tentative or cancelled events/tasks → no visual status mark on tentative or cancelled events/tasks
(Assignee)

Comment 15

10 years ago
It seems to me that it would be most intuitive to have cancelled events as line-through and tentative ones opaque.

I've been experimenting with calendar code a bit and I couldn't make events line-through in day and week view even though it was easily doable in weeks and month view. I suspect it might have something to do with Bug 58788.

Transparency is easy too, but I wouldn't know about weak vision, to me it seems that opacity 0.6 is different enough for normal vision and not too different for weak vision.

I also tried adding icons and to my surprise succeeded, but I used a fake one. To actually implement icons I'd need one for tentative and one for cancelled. I'm not too satisfied how it limits the viewable part of event name though. Consider an event with both reminder and status, there's not much space left for text in month view for example.

Thoughts?
(Assignee)

Comment 16

10 years ago
Created attachment 365708 [details] [diff] [review]
diff for icons

Proposing a patch.

Couldn't find invitation-status used anywhere so I believe it's redundant.

Comment 17

10 years ago
Merike: see http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree

> It seems to me that it would be most intuitive to have cancelled events as
> line-through and tentative ones opaque.

This didn't work out? Sounded like a good idea to me, esp. line-through for cancelled.
Assignee: nobody → gasell+mozilla
(Assignee)

Comment 18

10 years ago
Created attachment 366093 [details] [diff] [review]
underline-opacity version

(In reply to comment #17)
> > It seems to me that it would be most intuitive to have cancelled events as
> > line-through and tentative ones opaque.
> 
> This didn't work out? Sounded like a good idea to me, esp. line-through for
> cancelled.

It got rather tricky. Apparently xul:description tag (used in day and multiday view for not all day events) only applies text-decoration if text is set as a value, not if it's set inside the tag (Bug 422688). But if it is set as a value then it won't wrap, which is useful and used currently. Tried a html:div workaround suggested in bug but it behaves different to description when it comes to wrapping in rotated view. 

Attaching diff with changes I made in case there exists a xul element that would wrap it's text and apply text-decoration at the same time in both rotated and normal view or someone has an idea for a different workaround.
Attachment #366093 - Attachment is patch: true
Merike, if you want to have a core developer to look at your code you should ask for review for your patch. Also have a look at https://wiki.mozilla.org/Calendar:Review_Process for a description of the process. Thanks for looking at the code, and providing a patch. :)
Status: NEW → ASSIGNED
(Assignee)

Comment 20

10 years ago
Created attachment 367081 [details] [diff] [review]
underline-opacity v2

Found out why it didn't wrap, not sure how the calculation produced correct results before.
Attachment #366093 - Attachment is obsolete: true
Attachment #367081 - Flags: review?(mschroeder)
Comment on attachment 367081 [details] [diff] [review]
underline-opacity v2

Not enough time for a review. Shifting review to Philipp.
Attachment #367081 - Flags: review?(mschroeder) → review?(philipp)
Comment on attachment 367081 [details] [diff] [review]
underline-opacity v2

>diff -r be064d80219d calendar/base/content/calendar-multiday-view.xml
>--- a/calendar/base/content/calendar-multiday-view.xml	Thu Mar 12 08:52:27 2009 +0000
>+++ b/calendar/base/content/calendar-multiday-view.xml	Thu Mar 12 20:20:21 2009 +0200
>@@ -1903,7 +1903,8 @@
>                          xbl:inherits="context,parentorient=orient,readonly,flashing,alarm,allday,priority,progress,status,calendar,categories">
>                 <xul:image flex="1" class="calendar-event-box-gradient"/>
>                 <xul:vbox class="calendar-event-details" anonid="calendar-event-details">
>-                  <xul:description anonid="event-name" class="calendar-event-details-core" flex="1"/>
>+                  <!-- replace with <xul:description>, when #422688 is fixed -->
>+                  <html:div anonid="event-name" class="calendar-event-details-core" flex="1"/>
I'd actually second Neil's workaround comment in bug 422688. If you use:

<xul:description anonid="event-name" class="calendar-event-details-core" flex="1">
  <html:div anonid="event-name-div"/>
</xul:description>

Then you don't need extra rules for the html display:none and can just set hidden="true" on the description.

>+          if(this.orient == "vertical") {
>           evl.setAttribute("style", "max-height: " + Math.max(0, height-gripbar*2) + "px");
>+          } else {
>+          evl.setAttribute("style", "max-height: " + Math.max(0, height) + "px");
>+          }
Fix indent here.

>+calendar-event-box[selected="true"] .calendar-color-box {
>+    color: #000000 !important;
> }
Is this rule really wanted? black text as important?



>+calendar-event-box[status="tentative"],
>+calendar-editable-item[status="tentative"],
>+calendar-month-day-box-item[status="tentative"] {
I'd prefer using caps for the status like everywhere else.


r=philipp with comments fixed, please attach a new patch.
Attachment #367081 - Flags: review?(philipp) → review+
(In reply to comment #22)

>>+calendar-event-box[selected="true"] .calendar-color-box {
>>+    color: #000000 !important;
>> }
> Is this rule really wanted? black text as important?

I haven't looked intensively at the patch, but whatever happens, we shouldn't be using hardcoded text-colors, when there are suitable system-color alternatives.
(Assignee)

Comment 24

10 years ago
Created attachment 367660 [details] [diff] [review]
underline-opacity v3

(In reply to comment #22)
> I'd actually second Neil's workaround comment in bug 422688. If you use:
> 
> <xul:description anonid="event-name" class="calendar-event-details-core"
> flex="1">
>   <html:div anonid="event-name-div"/>
> </xul:description>
> 
> Then you don't need extra rules for the html display:none and can just set
> hidden="true" on the description.
> 
As far as I understand setEditableLabel in calendar-multiday-view.xml sets textContent using eventNameLabel in calendar-view-core.xml which matches anonid="event-name". So if the description tag keeps it's anonid then inner div will get replaced with text. If anonid of description is changed and div has anonid="event-name" then this won't be a problem, but it still requires extra css rule to hide the div.

> Is this rule really wanted? black text as important?
One of them is, to avoid white line on black text if events use dark background. Important not needed though.

> >+calendar-event-box[status="tentative"],
> >+calendar-editable-item[status="tentative"],
> >+calendar-month-day-box-item[status="tentative"] {
> I'd prefer using caps for the status like everywhere else.
It is set in lowercase so consistency in css brings 
-              this.setAttribute("status", item.status.toLowerCase());                                                       
+              this.setAttribute("status", item.status);   
in calendar-view-core.xml, else style isn't applied.

(In reply to comment #23)
> I haven't looked intensively at the patch, but whatever happens, we shouldn't
> be using hardcoded text-colors, when there are suitable system-color
> alternatives.
I wouldn't consider it hardcoded, this and some similar ones already in css assume that on dark backgrounds white is the best contrasting color and on light backgrounds black is the best. Background color here is either default or picked by user as it is set per calendar for all events and tasks.
Attachment #367081 - Attachment is obsolete: true
Comment on attachment 367660 [details] [diff] [review]
underline-opacity v3

r?=me to make sure I don't forget about this bug. I'll read the comment in detail soon and then take care of the checkin.
Attachment #367660 - Flags: review?(philipp)
Created attachment 370727 [details] [diff] [review]
underline-opacity v4

Sorry for the delay and that I didn't notice this earlier. For some reason I though this bug already had a positive UI review, but back in comment 13 I see Christian gave ui-review- and noting we should use icons instead.

Christian, maybe you want to revise this decision? In any case, this patch needs a ui-review. Bryan, could you take a look?

I've changed the patch a bit so you know what I meant with dropping the div[hidden="true"] rule, let me know if you don't agree to the way I've changed the patch.
Attachment #367660 - Attachment is obsolete: true
Attachment #370727 - Flags: ui-review?(clarkbw)
Attachment #367660 - Flags: review?(philipp)
Personally I think the patch with line-through is fine, but I can see the reasoning behind not doing so (i.e it obstructs the user to read the text)
Comment on attachment 370727 [details] [diff] [review]
underline-opacity v4

Can you add the line-through to this patch?

I think christian has a good point, icons would differentiate these two types.  I think the line-through would clearly indicate that also.  I'm not sure I understand why it wouldn't work out.
Bryan, the underline-opacity patch adds line-through to cancelled events and gives tentative events a lower opacity. This is working fine in v4.
(Assignee)

Comment 30

10 years ago
Created attachment 371057 [details]
screenshot (line-through & opacity)

(In reply to comment #29)
> Bryan, the underline-opacity patch adds line-through to cancelled events and
> gives tentative events a lower opacity. This is working fine in v4.
Did you check multiweek views? These miss event name for me if built with v4. I also tested v4 without changes to calendar-view-core.xml setEditableLabel method and it looked fine then.

Sorry for the naming confusion, it must be that I tested with underline when I couldn't make line-through work and it took over my thinking :).

Attaching screenshot for line-through & opacity too.
I vote against using reduced opacity. It reduces legibility and it makes Sunbird/Lightning less usable for users requiring high color contrasts. In addition I think it might reduce event to calendar recognition, i.e. an opaque light blue event from calendar A versus a translucent blue event from calendar B.

Comment 32

10 years ago
How about italic for tentative? Or maybe i've been looking at UNCONFIRMED in bugzilla too much;)
Attachment #370727 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 370727 [details] [diff] [review]
underline-opacity v4

cool!
Bryan, what about comment #31 ?

Comment 35

10 years ago
+1 for ssitter, I think italic or perhaps just a reduced color for the text, not for the box, would be best.
Whiteboard: [needs decision on comment#31]
Attachment #219437 - Attachment is obsolete: true
Attachment #219450 - Attachment is obsolete: true
Attachment #365708 - Attachment is obsolete: true
Bryan, what do you think about the concerns in comment#31?
Sorry for the delay philipp I missed your comment.  By changing opacity on the tentative events we are actively trying to reduce its visual presence.  Reduced visual presence often comes with reduced legibility so it has to be used carefully.

Italics would provide a difference however I don't think it puts elements in the background, in typography italics is most often used to provide emphasis on text; the opposite of what we want.

For high contrast concerns each OS handles high contrast differently.  In Linux it's a theme that can't be detected so we have to default to the small set of ugly System CSS colors.  In Windows the default theme is detectable so our CSS can default to system colors when needed.  With the Mac it actually does high contrast at the video display level (arguably the best method) as if it were photoshop pulling the contrast from images; this means we don't need to do anything special.

Any change of the background color is going to lead the possibilities of clashing with other calendar colors so we either need to accept that or find another way.  The background color clash problem assumes that this user had two very similar colors already chosen and that the difference in text color isn't noticed; a very possible but not high probability (IMO) case.

Overall I'm not too concerned as I think we want tentative events to fade out from the other events in the way the reduced opacity changes.  Other methods we tried, like a border or alternate text formatting made tentative events stand out more; the opposite of our desired effect.  

If we have an alternate implementation that achieves the same goals I'm certainly open to exploring it.
Philipp, can you take care of checkin (and possible adjustments to the patch)?
Whiteboard: [needs decision on comment#31]
Comment on attachment 371057 [details]
screenshot (line-through & opacity)

Yes, I'll take care. Setting review of this attachment to myself, to make sure its in my queue. This is not a formal review request.
Attachment #371057 - Flags: review?(philipp)
Looking at this again, it seems that tentative events are less prominent than cancelled events. I'd suggest to make cancelled events both have less opacity (like tentative events) and have line-through.

Thoughts?
Attachment #371057 - Flags: review?(philipp)
clarkbw agrees via IRC.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ea1db982e51e>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
This bug broke cropping and the alarm icon moves somewhere it shouldn't be. bug 413594 has been reopened to hopefully fix this issue.
Reopening this bug, I've backed out this changeset so we can proceed on the beta and get bug 501302 off of the beta blocker list. We should fix this after the beta though.

Backout changeset is ec2dc96b863b
Status: RESOLVED → REOPENED
Flags: blocking-calendar1.0+
Resolution: FIXED → ---
Whiteboard: [not needed beta][no l10n impact]
Duplicate of this bug: 404179

Comment 45

9 years ago
I would like to propose something else:

Just add a "TENTATIVE:" or "CANCELLED:" bolded word to the event's subject. 

What do you think?
(In reply to comment #45)

Takes up to much space that is required to view the actual event title. In addition you can already do this yourself by changing the title if you change the status.
(Assignee)

Comment 47

8 years ago
Apparently the issue from Bug 422688 is now fixed in 1.9.3, but not in 1.9.2 which Lightning currently uses.

Which of the following makes most sense?
 1. Postpone implementing this entirely until Lightning uses 1.9.3
 2. Do opacity 0.6 for tentative and 0.5 for cancelled for now and add line-through when 1.9.3 is used.
 3. Something else?
Whiteboard: [not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs decision]
(In reply to comment #47)
> Apparently the issue from Bug 422688 is now fixed in 1.9.3, but not in 1.9.2
> which Lightning currently uses.

Merike, Wladimir Palant reported the issue is also fixed in 1.9.2, can you verify this?
(Assignee)

Comment 49

8 years ago
> Merike, Wladimir Palant reported the issue is also fixed in 1.9.2, can you
> verify this?

You mean 1.9.1? Because he reported Firefox 3.5 not Firefox 3.6.

When using <description value="text"/> it is indeed fixed in 1.9.1 already. But when using <description>text</description> which is needed for this bug, it is only fixed in 1.9.3.
Which means we might be lucky, Lightning 1.0b3 will likely be based off 1.9.3
Status: REOPENED → ASSIGNED
Whiteboard: [not needed beta][no l10n impact][needs decision] → [not needed beta][no l10n impact]
Target Milestone: 1.0 → ---
(Assignee)

Comment 51

8 years ago
Created attachment 500237 [details] [diff] [review]
1.9.3 version

Taking another try with this :).

This should be the same as backed out version except that:
* it doesn't change dom which caused issues and isn't necessary any more
* works only on trunk
* instead of adding rules for black text it modifies present rules to cover the case where title is black and strike would be white otherwise

Last one should be safe to change because .calendar-event-selection is the only element contained in .calendar-color-box.
Attachment #500237 - Flags: review?(philipp)
Comment on attachment 500237 [details] [diff] [review]
1.9.3 version

Very fine solution, thanks for the patch! r=philipp
Attachment #500237 - Flags: review?(philipp) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4e62ac868a7b>
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk

Comment 54

8 years ago
(In reply to comment #52)
> 1.9.3 version
(In reply to comment #53)
> -> FIXED

Please pardon my ignorance: Isn't 1.9.3 the *trunk* for Thunderbird? I thought Lightning trunk doesn't work with Thunderbird trunk. At least it hasn't for a very long time. Has that changed?
Yes, 1.9.3 is now 2.0, aka trunk. Lightning trunk now works again, see http://weblogs.mozillazine.org/calendar/2011/02/lightning_trunk_is_back_on_tra.html
You need to log in before you can comment on or make changes to this bug.