Closed Bug 374464 Opened 13 years ago Closed 11 years ago

Context menu: rename Edit Item / Delete Item entry to Edit / Delete

Categories

(Calendar :: Calendar Views, defect, minor)

defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: berend.cornelius09, Assigned: berend.cornelius09)

References

(Depends on 1 open bug)

Details

(Keywords: late-l10n, polish)

Attachments

(2 files, 3 obsolete files)

the event summary dialog may be raised by a context menu over the appropriate event. However the label of the respective menu item is "edit item". This should be changed. Above that I generally think the expression "edit item" - even for an editable event- is very technical and should be changed to something like "edit event" or "edit task". Respectively the expression "Item" should be changed in other menu items of this context menu, too.
See Bug 369934 for a similar issue with Sunbird where 'Edit Event' is used in the context menu causing troubles.

I assume that the context menu is context sensitive. Therefore it makes no sense to duplicate the information about event/task into the context menu. 
So the menu item should be just 'Edit' or 'Delete' in my opinion.
Generally I find the suggestion from Stefan reasonable, but I'd like to hear Christian opinion on this.

Furthermore, I'm going to remove the dependence on the event summary dialog and alter the bug title, since this has nothing to do with the event dialog (read-only or otherwise), it belongs to the views.
Assignee: Berend.Cornelius → nobody
Severity: normal → minor
Component: General → Calendar Views
No longer depends on: 361977
OS: Solaris → All
QA Contact: general → views
Hardware: Sun → All
Summary: getting information about readonly event- menu items in context menu is bad → menu items in context menu is bad
Target Milestone: Future → ---
Christian, can you make a decision, how to proceed. 
Assignee: nobody → christian.jansen
When this decision is made, we need to also unify the context menu between lightning and sunbird.
Depends on: 340025
I would like to have this for 0.8 target and suggest to follow Stefan's proposal in comment #3 and Pilipp's proposal in comment #4.
Flags: wanted-calendar0.8?
Christian, we're still waiting for a decision from you here...

Whatever the answer, this does *not* warrant wanted0.8+
Flags: wanted-calendar0.8? → wanted-calendar0.8-
Keywords: polish
(In reply to comment #6)
> Christian, we're still waiting for a decision from you here...

We are waiting for the final proposal in Bug 340025 to be correct. For that proposal this bug and bug 369934 should be considered too.
I've made no decision, but I've created proposal [1]. I think this is a good base for a general discussion on how we want to structure the context menus. As always feedback and comments are welcome.

[1] http://wiki.mozilla.org/Calendar:Context_Menu_Specification
(In reply to comment #8)
> As always feedback and comments are welcome.

I'm happy to offer my opinions.  :)

1) Overall, very nice.  I like the proposed ability to send emails to the organizer/attendees.

2) Perhaps it's a little too complicated?  I think that "Make Standard Event" and "Make Allday Event" could be removed.  Besides, if I right click on an allday event and click "Make Standard Event", how am I going to enter the Start and End times unless I open the event dialog?  So I might as well open the event dialog in the first place.  So I don't think that the context menu should distinguish between allday events and standard events.

3) I do think that it's a good idea to distinguish between recurring and non-recurring items.  What does "Stop Recurrence" mean, delete all future occurrences?  Maybe it should say "Delete future occurrences".  Then there should probably also be "Delete this occurrence" and "Delete all occurrences".  I know that that would be messy but I think that if there will be one of the special cases, then there should be all three.  Perhaps the context menu could just say "Delete" and then (for recurring items) a menu opens with the three special cases.  That would look nicer but it would be slower for the user to make a choice.

4) Of course the "Edit" menu item is very similar to the "Delete" item in (3).

5) Note that tasks can recur too.  I don't think that the chart indicates this.

6) I think that the "Private" menu item is unnecessary.  It seems to me that this is something that I set only once, when I create the event, and would never need to change the privacy state (under normal circumstances).  Anyway, if you keep this, I think that there are three choices (Public / Time & Date Only / Private).

7) Regarding the "Status" of the item (Tentative/Confirmed/Cancelled), this is not in your chart.  I admit that I've never used this Status feature in any calendar program, but if the user has to manually set this status for events, perhaps there should be a way to do it in the context menu?  Does only the meeting organizer set this status?  If so then maybe the Status menu item could appear only if the user is the organizer of the event that he right clicked.  That would be a very context-sensitive menu.  :)

8) There's the "Calendar" item (with example subitems: Private, Work, etc.).  I assume that this will allow us to copy the item to other calendars.  I'm very happy to have this feature.  Regarding the name of the menu item ("Calendar"), Thunderbird has two menu items:  "Copy to >" and "Move to >".  Perhaps Lightning/Sunbird could 'steal' this idea.  I think that when the user hovers the mouse over "Copy to >" and the submenu opens, that it will be obvious to the user that this is his list of calendars.  In addition to the ability to copy items among calendars, I think that it would also be useful to move items.

9) "Duplicate".  I would use this (especially if it preserved more information than using Ctrl-C/Ctrl-V).  I'm thinking that this would not have to be a separate menu item if it could be integrated into the "Copy to" menu (and to duplicate the item, we would copy it to the same calendar name).  The hard part, perhaps, is how do you indicate in the Copy To submenu the item's original calendar?

10) I'm wondering if there should be a way in the context menu of an event to create a task based on the event (and vice versa).  Also, there could be a way to compose a new email (based on the event/task) that can be sent to anyone (for events that are not meetings and thus don't have a list of attendees).  I'm not sure if I would ever use these features, but I just wanted to mention this.  Maybe this is for a future bug.
I'd say comments about the entire context menu rework should be posted to the corresponding Bug 340025.
Summary: menu items in context menu is bad → Edit Item / Delete Item in context menu is bad
Summary: Edit Item / Delete Item in context menu is bad → Context menu: rename Edit Item / Delete Item entry to Edit / Delete
Attached patch patch v. #1 (obsolete) — Splinter Review
One very annoying thing about our context menu is certainly the "Edit Item" menuitem. This expression is very technical and should therefor be replaced. Therefor I set up the following strings for this menuitem that are set, depending on wether the selected item is an event or a task or wether it is readonly ("Open..") or not ("Edit...").

modifyTaskLabel=Edit Task…
openTaskLabel=Open Task…
modifyEventLabel=Edit…
openEventLabel=Open…
Assignee: christian.jansen → Berend.Cornelius
Status: NEW → ASSIGNED
Attachment #329462 - Flags: ui-review?(christian.jansen)
Attachment #329462 - Flags: review?(philipp)
Flags: wanted-calendar0.9?
Comment on attachment 329462 [details] [diff] [review]
patch v. #1

> 
>+function adaptModificationMenuItem(aMenuItemId, aItems, aItemType){
>+    var menuItem = document.getElementById(aMenuItemId);
Use:

   if (aItems.some(isCalendarWritable)) {

instead of only checking for aItem.calendar.readOnly. Also, please add some documentation to the function.


r=philipp
Attachment #329462 - Flags: review?(philipp) → review+
(In reply to comment #11)
> Created an attachment (id=329462) [details]
> patch v. #1
> 
> One very annoying thing about our context menu is certainly the "Edit Item"
> menuitem. This expression is very technical and should therefor be replaced.
> Therefor I set up the following strings for this menuitem that are set,
> depending on wether the selected item is an event or a task or wether it is
> readonly ("Open..") or not ("Edit...").
> 
> modifyTaskLabel=Edit Task…
> openTaskLabel=Open Task…
> modifyEventLabel=Edit…
> openEventLabel=Open…
> 

I'd like to see the following, like specified and discussed in:
http://wiki.mozilla.org/Calendar:Context_Menu_Specification
Attached patch [checked in] patch v. #2 (obsolete) — Splinter Review
patch with the new resources as demanded from Christian
Attachment #329686 - Flags: review?(daniel.boelzle)
Flags: wanted-calendar0.9?
Flags: wanted-calendar0.9+
Flags: wanted-calendar0.8-
Comment on attachment 329686 [details] [diff] [review]
[checked in] patch v. #2

>+<!ENTITY calendar.context.deletethisEvent.label       "This Event">
>+<!ENTITY calendar.context.deletethisEvent.accesskey   "T">
>+<!ENTITY calendar.context.deletecompleteSeries.label  "Complete Series">
>+<!ENTITY calendar.context.deletecompleteSeries.accesskey   "S">
>+<!ENTITY calendar.context.deletefutureEvents.label     "All Future Events">
>+<!ENTITY calendar.context.deletefutureEvents.accesskey "F">
>+<!ENTITY calendar.context.deletefutureTasks.label     "All Future Tasks">
>+<!ENTITY calendar.context.deletefutureTasks.accesskey "F">
please use all lower-case

r=dbo
Attachment #329686 - Flags: review?(daniel.boelzle) → review+
modifed resources and checked in patch on trunk and MOZILLA_1_8_BRANCH
You need to change the entity name if you change the meaning of the entity, e.g. "Edit Task" -> "Open Task", "Delete Item" -> "Delete", etc.
Otherwise translation team will most probably not pick up the changes.
Attachment #329686 - Attachment description: patch v. #2 → [checked in] patch v. #2
@Stefan: Thanks again for your hint. I modified the last patch and introduces new entities. I had to keep the old entities as the final implementation of the patch is not yet ready or reviewed.
@Daniel: I also had to introduce resources in the calendar.properties file. At first these might appear redundant to the entities in the dtd file, but the reason for theses strings is that I have to apply them during runtime to the menuitems of the context menu, depending on whether the selected item is an event or a task. Hiding one menuitem during "popupshowing" does not work on all operating systems (Mac).
Attachment #329796 - Flags: review?(daniel.boelzle)
Attachment #329796 - Flags: review?(daniel.boelzle) → review+
patch with new strings checked in on trunk and MOZILLA_1_8_BRANCH
Attachment #329796 - Attachment description: patch with new strings → [checked in] patch with new strings
Keywords: late-l10n
Target Milestone: --- → 0.9
Attached patch patch v. #3 (obsolete) — Splinter Review
I modified the patch conforming to the specification that Christian mentioned in comment #13 (http://wiki.mozilla.org/Calendar:Context_Menu_Specification) and ask again for review from Philipp because the implementation has changed.
Attachment #330029 - Flags: ui-review?
Attachment #330029 - Flags: review?(philipp)
Attached patch patch v. #3Splinter Review
I modified the patch conforming to the specification that Christian mentioned in comment #13 (http://wiki.mozilla.org/Calendar:Context_Menu_Specification) and ask again for review from Philipp because the implementation has changed.
Attachment #329686 - Attachment is obsolete: true
Attachment #330030 - Flags: ui-review?(christian.jansen)
Attachment #330030 - Flags: review?(philipp)
Attachment #330029 - Attachment is obsolete: true
Attachment #330029 - Flags: ui-review?
Attachment #330029 - Flags: review?(philipp)
Attachment #330030 - Flags: review?(philipp) → review+
Attachment #330030 - Flags: ui-review?(christian.jansen) → ui-review+
ui=christian
patch checked in on trunk and MOZILLA_1_8_BRANCH
->FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #329462 - Attachment is obsolete: true
Attachment #329462 - Flags: ui-review?(christian.jansen)
Attachment #329462 - Flags: review+
Checked in lightning 2008082103 and sunbird 20080820 -> VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.