Community
Participate
Working Groups
Popup menu in the Task List view need to be rearranged. Currently we have number of items at the root (i.e. Copy context to..., Clear, Attach and Retrieve context) that are used less often then items from the Mark submenu (complete/incomplete, read/unread). I am suggesting to move context-related actions into submenu and move "mark" actions out of the submenu.
BTW, the most used action for me is Mark as Read.
(In reply to comment #1) > BTW, the most used action for me is Mark as Read. Exactly! Hopefully new monitor reporting will help us to convince Mik about that, though he publically admitted that he never uses those Context... actions himself.
(In reply to comment #2) > Exactly! Hopefully new monitor reporting will help us to convince Mik about > that, though he publically admitted that he never uses those Context... actions > himself. > I use Attach/Retrieve Context sometimes, but not so frequently as Mark as Read. The Copy Context could be moved into some type of workflow, like turning a local task into a repository task.
(In reply to comment #2) > Exactly! Hopefully new monitor reporting will help us... Humm... tell me more about this monitor reporting thing... are you planning a new round of user study?
Another thoughts: - I never used the "Activate" action. If using mouse I usually click on the bullet on task list. If using keyboard, I use Ctrl+F9 shortcut key. - Open/Open with Browser: the same. Double-click when using mouse; <ENTER> on task list or Ctrl+F12 with keyboard. Regarding "Open with Browser": I request this a long time ago, when the task editor was not very friendly. Today I can say that I'm confortable using it instead of browser when acessing task inside Eclipse. - The contexts actions could be grouped into a submenu, and the mark actions be moved to a top level group.
(In reply to comment #5) > - I never used the "Activate" action. If using mouse I usually click on the > bullet on task list. If using keyboard, I use Ctrl+F9 shortcut key. I am using those from the editor popup menu. Still can't remember those shortcuts... > - The contexts actions could be grouped into a submenu, and the mark actions be > moved to a top level group. That is the primary issue in this bug report.
(In reply to comment #6) > (In reply to comment #5) > > - The contexts actions could be grouped into a submenu, and the mark actions > be > > moved to a top level group. > That is the primary issue in this bug report. Ooops... I forgot that...
Mik, are you planning to move "mark..." out of the submenu of the Task List popup menu? I logged bug 184564 to show top commands/actions on the community stats web page, but it doesn't seem getting any attention either.
(In reply to comment #8) > Mik, are you planning to move "mark..." out of the submenu of the Task List > popup menu? I would like the incoming indicator to be clickable for mark read/unread to make this action as easy as possible, in addition to keeping the context menu. But note that it will have to be in a seprately distinguishable column (not icon overlay) for me to add this, because it is too weird to have a hot spot on an icon region (even though it is not hard to implement). If on bug 182772 we settle on something like the current implementation with a distinct column the single-click mark read will be done this week. > I logged bug 184564 to show top commands/actions on the community stats web > page, but it doesn't seem getting any attention either. Comments on that bug, I also want it before we go out with the UI Usage Reports.
(In reply to comment #9) > I would like the incoming indicator to be clickable for mark read/unread to > make this action as easy as possible, in addition to keeping the context menu. > But note that it will have to be in a seprately distinguishable column (not > icon overlay) for me to add this, because it is too weird to have a hot spot on > an icon region (even though it is not hard to implement). If on bug 182772 we > settle on something like the current implementation with a distinct column the > single-click mark read will be done this week. It don't like how are you using bug 182772 as an excuse not to rearrange pop up menu... Also it doesn't seem like it is a really good idea to use single-click to remove incoming indicator.
I was not using it as an excuse--UI design needs to be holistic and I had a request to make incoming clickable before I started on the Task List layout changes. It's simple: 1) If we are able to do single-click "mark read" we don't need to make mark actions use real-estate in the top-level menu. 2) If we do, we need to consider it. I almost never use "mark read", but I know that others like you (and Gail Murphy) use it constantly. She requested the single-click mark read/unread, so if you think it is a bad idea please outline the reasons. I like it because the affordance has a clear action associated with it.
(In reply to comment #11) > I almost never use "mark read", but I know that others like you (and Gail > Murphy) use it constantly. She requested the single-click mark read/unread, so > if you think it is a bad idea please outline the reasons. I like it because > the affordance has a clear action associated with it. You can only do so much with those icons and we have both mark as read and mark as completed actions. Also clicking on icon is not keyboard friendly, I sometimes call popup menu from the keyboard, and sometimes with mouse, but always wanted to hit an accelerator key that would work fine if those actions are in popup menu. Anyways, I thought that we all agreed that context actions that currently sitting in the root of popup menu are less frequently used then actions from the "mark..." submenu.
Yes, the plan is to move the context actions into a sub menu.
(In reply to comment #13) > Yes, the plan is to move the context actions into a sub menu. Done. Eugene: I still can't figure out how to accomodate your request of having Mark Read not be in a sub-menu, because a naiive way of doing that would bring too many items into the context menu. Could you open up a new bug report for "make it easy to mark tasks read" where we can figure out a solution? For example, an alternative would be clicking the incoming arrow or better yet a button/link in our tooltip that displays the incoming info.
Created attachment 71559 [details] mylar/context/zip
(In reply to comment #14) > Eugene: I still can't figure out how to accomodate your request of having Please read comment #1. > Mark Read not be in a sub-menu, because a naiive way of doing that would > bring too many items into the context menu. All one or two of them? > Could you open up a new bug report for "make it easy to mark tasks read" > where we can figure out a solution? Are you jeer at me? This bug report been opened upon your request, so somebody can figure out way to shuffle menu items around. Now that you have stats on most frequently used actions, why don't we use it to make this decision? > For example, an alternative would be clicking the incoming arrow or > better yet a button/link in our tooltip that displays the incoming info. Which won't work without a mouse, and when decoration is used instead of the incoming arrow.
I am not jeering, I just wanted a separate bug report because I did the context menu part of the work. If you like you can reopen this and I'll move the milestone because I'm not sure if we can converge on this for 2.0. But we can try. Et is very unlikely that we have enough usage stats at this point to influence the decision so I was planning on putting off writing the stats parsers until after 2.0. Please write out the modified context menu hierarchy that you would like to see. The problem I'm seeing is that we end up with both a "Mark Read" action and a "Mark" submenu, which will need to also have that action.
Well, I guess this is sounds too ridiculous to me, so I can't be constructive about it. Besides, I don't see how separate bug report is going to help when you are against this simple menu rearrangement.
I am not inherently opposed, just want to make sure the menu looks and feels consistent. From comment#17: "Please write out the modified context menu hierarchy that you would like to see" and we can consider it.
Commenting here as suggested in bug 186715: need capability to reverse sort order in task list. Thanks!
Did you mean that you want those sort actions on the popup menu? I'm not sure that it is worth the real-estate because it doesn't seem like it would save any clicks overall. Regarding reversing any of the sort orders please create a new bug report with a use case for the specific reverse order (in case we can keep the UI simple and add it as another ordering rather than additional UI for reversing).
(In reply to comment #21) > Regarding reversing any of the sort orders please create a new bug report with > a use case for the specific reverse order (in case we can keep the UI simple > and add it as another ordering rather than additional UI for reversing). I thought there is a bug for that already. Anyways, descending sorting (which can be a single check-menu item) would be useful for at least sorting by summary/key, by creation date and by last updated date. Adding 3 additional soring for those would be more expensieve and would take more real estate then simple checkbox.
Why is descending by summary/key useful? Isn't that just date created?
(In reply to comment #23) > Why is descending by summary/key useful? Isn't that just date created? Nope. For example jira query could pick multiple projects, so it would order by project + id in case of "summary" sorting, and for "creation date" issues from different projects will be interleaved.
regarding comment 23: use case is to have the most recently created bugs on top
