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

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Berend Cornelius]

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.

Comment 1

[Stefan Sitter [:ssitter]]

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.

Comment 2

[Michael Büttner (no reviews TFN)]

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.

Comment 3

[Berend Cornelius]

Christian, can you make a decision, how to proceed. 

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

When this decision is made, we need to also unify the context menu between lightning and sunbird.

Comment 5

[Berend Cornelius]

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.

Comment 6

[Simon Paquet [:sipaq]]

Christian, we're still waiting for a decision from you here...

Whatever the answer, this does *not* warrant wanted0.8+

Comment 7

[Stefan Sitter [:ssitter]]

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

Comment 8

[Christian Jansen]

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

Comment 9

[Pete Riley]

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

Comment 10

[Stefan Sitter [:ssitter]]

I'd say comments about the entire context menu rework should be posted to the corresponding Bug 340025.

Comment 11

[Berend Cornelius]

Attachment: 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…

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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

Comment 13

[Christian Jansen]

(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

Comment 14

[Berend Cornelius]

Attachment: [checked in] patch v. #2

patch with the new resources as demanded from Christian

Comment 15

[Daniel Boelzle [:dbo]]

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

Comment 16

[Berend Cornelius]

modifed resources and checked in patch on trunk and MOZILLA_1_8_BRANCH

Comment 17

[Stefan Sitter [:ssitter]]

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.

Comment 18

[Berend Cornelius]

Attachment: [checked in] patch with new strings

@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).

Comment 19

[Berend Cornelius]

patch with new strings checked in on trunk and MOZILLA_1_8_BRANCH

Comment 20

[Berend Cornelius]

Attachment: patch v. #3

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.

Comment 21

[Berend Cornelius]

Attachment: patch v. #3

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.

Comment 22

[Christian Jansen]

ui=christian

Comment 23

[Berend Cornelius]

patch checked in on trunk and MOZILLA_1_8_BRANCH
->FIXED

Comment 24

[Andreas Treumann]

Checked in lightning 2008082103 and sunbird 20080820 -> VERIFIED