Bug 1609977 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Magnus Melin [:mkmelin] from comment #1)
> You can compare these to nicely formatted text and for text Copy/Paste/Cut/Delete are the norm. So I don't agree.

Good point, thanks. I don't have strong feelings about this bug.

I guess there are two legitimate perspectives / design concepts for the recipients - text and items - and both of them are present in the current implementation. The newer and more eyecatching concept (wrt TB's history) is items (aka "pills"), and Alessandro once said he's trying to emphasize that. Again, I don't have strong feelings either way, and I'm on record to suggest merging the best of both worlds.

For this bug, if you look at recipients as text, then yes - it should be plain vanilla Cut/Copy/Paste/Delete - that's totally OK, nice and terse, and consistent with the notion of "text".

For others looking at recipients as items (which they *also* are), the notion is more like |Cut/Copy/Paste *selected items*|, so "Remove recipient(s)" might match that conccept better. I took a leaf from composition's attachment pane where also have "Remove Attachments" to avoid the impression of deleting the underlying file, and to be clearer about what exactly is going to be removed (note that most other commands do *not* have the term "Attachments"). Deleting/removing things is always a bit delicate (more so if it can't be undone), so being explicit about the object of deletion/removal might make users feel a little safer... Also in terms of internal ux-consistency, we usually try to use the same terms for the same action. So from an "items" perspective, matching the traditional context menu may for text may seem less attractive.
(In reply to Magnus Melin [:mkmelin] from comment #1)
> You can compare these to nicely formatted text and for text Copy/Paste/Cut/Delete are the norm. So I don't agree.

Good point, thanks. I don't have strong feelings about this bug.

I guess there are two legitimate perspectives / design concepts for the recipients - text and items - and both of them are present in the current implementation. The newer and more eyecatching concept (wrt TB's history) is items (aka "pills"), and Alessandro once said he's trying to emphasize that. Again, I don't have strong feelings either way, and I'm on record to suggest merging the best of both worlds.

For this bug, if you look at recipients as text, then yes - it should be plain vanilla Cut/Copy/Paste/Delete - that's totally OK, nice and terse, and consistent with the notion of "text".

For others looking at recipients as items (which they *also* are), the notion is more like |Cut/Copy/Paste *selected items*|, so "Remove recipient(s)" might match that conccept better. I took a leaf from composition's attachment pane where also have "Remove Attachments" to avoid the impression of deleting the underlying file, and to be clearer about what exactly is going to be removed (note that most other commands do *not* have the term "Attachments"). Deleting/removing things is always a bit delicate (more so if it can't be undone), so being explicit about the object of deletion/removal might make users feel a little safer... Also in terms of internal ux-consistency, we usually try to use the same terms for the same action. So from an "items" perspective, matching the traditional context menu for text may seem less attractive.

Back to Bug 1609977 Comment 2