+++ This bug was initially created as a clone of Bug #512375 +++ There are still some important items missing from the "other actions" menu. At the very least, we want mark-as-(read|unread), and once GloDa lands, we probably will want show-in-conversation as well. A variety of other possibilities are discussed in bug 512375.
One thing to think about with this is whether or not mark-as-(read|unread) is appropriate for threads/multi-message summaries as well as individual messages. That might be a different bug though, since there are probably other commands that make sense for the multi-message summary (e.g. "junk").
I suspect it is relevant for those things as well, but, as you say, that should be a separate bug.
Oh, now I remember why I was concerned about multi-message summaries in comment #1: mark-as-read is a little more complicated with multiple messages, since they might not all have the same state. This is already a bit of a problem when right-clicking on multiple messages, since it uses the read-state of the first message to determine what action to perform. It would be nice if there was a single UI for this. All this is pursuant to my plan to see if we can't use the same buttons for the message header and the multi-message summary. It would certainly make it easier if/when those buttons become customizable (which I think would ease a lot of people's complaints about them).
(In reply to comment #3) > Oh, now I remember why I was concerned about multi-message summaries in comment > #1: mark-as-read is a little more complicated with multiple messages, since > they might not all have the same state. This is already a bit of a problem when > right-clicking on multiple messages, since it uses the read-state of the first > message to determine what action to perform. I'm not convinced that modeling all the nuance here is actually likely to do what the user wants the majority of the time. Which is to say that the menu item probably wants to read either "Mark as Read" or "Mark as Unread" (ie "Toggle Unread" strikes me as something that would correctly model this, but it seems like it's likely to confuse a bunch of people). How about just picking the state of the first message, like the right click already does, making the menuitem display the text appropriate for that message, and then at selection time, apply that state to all the messages? > It would be nice if there was a single UI for this. We don't currently have an "other actions" menu for the multi-message selection screen, and it feels late in the game to add one (string freeze is this coming Tuesday the 29th, so all string changes need to be reviewed and landed in the tree by then). > All this is pursuant to my plan to see if we can't use the same buttons for the > message header and the multi-message summary. It would certainly make it easier > if/when those buttons become customizable (which I think would ease a lot of > people's complaints about them). The customizability bug for the regular header will be landed by string freeze. I agree that there's merit to the idea of making the multi-message header customizable too, but that sounds like a post-Tb-3.0 feature.
Looks like we'll be getting "show in conversation" in bug 478989.
Summary: add important "other actions' (mark as read, show in conversation) to default set → add "mark as read/unread" to default set of actions in "other actions" menu
I think the checkbox state for "Mark > As Read" is confusing and incorrect, especially for the multi-message scenario. I'd recommend what I think dmose is saying here that we should move to individual menu items that appear or disappear as appropriate. When you have a multiple selection of mixed read and unread you simply show both actions: "Mark as Read" , "Mark as Unread" to the user. Otherwise, what often happens to me, the user has to mark all the messages as unread and then again to make them read; it's confusing and 2 actions to do what the user already knew they wanted.
That's close to what I was saying; I think what you propose, however, actually makes more sense than what I was saying. :-)
Yeah, I'd agree with that too. So for this bug, the solution would be to add "mark as read" or "mark as unread" as appropriate to the other actions menu, and then (probably in another bug), to change the context menu behavior when clicking on messages.
right, that sounds like a good plan to me
Created attachment 402906 [details] [diff] [review] Add "mark as read/unread" to "other actions" menu Here's a patch that adds mark as read/unread to the other actions menu. I considered adding a separator after the new item to match with the context menu in the message list, but I don't think it's necessary at this point.
Comment on attachment 402906 [details] [diff] [review] Add "mark as read/unread" to "other actions" menu oh wow, it's so simple and easy to use! Agreed that we don't need a separator at this point.
Attachment #402906 - Flags: ui-review?(clarkbw) → ui-review+
Created attachment 403713 [details] [diff] [review] patch, v2 (checked in) Fixed bitrot induced by one of the many patches that landed in the past few days. Patch itself looks good, r=dmose.
Attachment #403713 - Attachment description: patch, v2 → patch, v2 (checked in)
Thanks so much for the patch, Jim! Pushed: http://build.mozillamessaging.com/mercurial/comm-central/rev/e28f4a7321eb
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.