GNOME Bugzilla – Bug 559256
Provide visual indication of composer options
Last modified: 2015-04-29 16:35:19 UTC
Evolution's mail composer supports several toggle options, including requesting a read receipt, tagging a message as high priority, and various security features. Some of these options can be automatically enabled when composing a new message. The problem is there's no visual feedback in the composer window as to which options are enabled. The only visual clue is a checkmark buried in the main menu next to the option. If the user is expecting certain options to be enabled automatically and for some reason they aren't, such as say the security features, this can lead to mistakes like sending unencrypted sensitive data. I was playing around with an idea yesterday of adding a small message to the composer window when a toggle option is enabled. Each message contains a short description along with a button to disable the option. The possible messages (along with the disable buttons) read as follows: This is a high priority message. [Remove Priority] You are requesting a read receipt for this message. [Remove Receipt ] This message will be encrypted with your PGP key. [Do Not Encrypt ] This message will be signed with your PGP key. [ Do Not Sign ] This message will be encrypted with your S/MIME [Do Not Encrypt ] encryption certificate. This message will be signed with your S/MIME signing [ Do Not Sign ] certificate. Screen shot to follow.
Created attachment 121943 [details] Screenshot Shows a couple options enabled.
Created attachment 121944 [details] [review] Proposed Patch
this is nice, but you realize this might lead to a big proportion of the composer window being useless for actual writing of the mail. Could you also get a condensed mode of this ?
Any specific suggestions?
hum nothing shacking but maybe something like the following would do it: The yellow area contains the icons corresponding to each option, inline (respecting gnome toolbar icons style maybe, like the component switcher) and below, in the same yellow zone, have an expander that shows what you have proposed in your screenshot. Maybe this shouldn't be a yellow zone at all though because it brings themability issues back on the table, try something like the nautilus extra widget bar (see trash, cd burner, search, ...) I can try to create a mockup of this if this is not clear enough.
I think I get what you're suggesting, but yeah a mockup would be good. As for themability, the "yellow zone" is actually "tooltip_bg_color" from GtkSettings. I don't have code in there to listen for theme changes, but that could be added easily. I'm wondering, though, whether screen real estate is really going to be an issue in practice. Maybe I'm wrong, but with the present set of options I envision a typical use case would have at most two, maybe three of them enabled. For me two would be tolerable, three is borderline. Would it help if I added a "View -> Option Status" toggle so users can just turn the feature off entirely?
May be you can move them as small-text-icons pair to the right bottom, instead of occupying a entire line.. Just a thought
(In reply to comment #7) > May be you can move them as small-text-icons pair to the right bottom, instead > of occupying a entire line.. Just a thought By "right bottom" do you mean across from the "Show Attachment Bar" label? Can you give an example? Like, what would it show if I had "Read Receipt", "Prioritize Message" and "PGP Encrypt" all enabled? I'm just gathering ideas here. Seems like we ought to display some kind of _readable_ indication (not just an icon), but I also know how anal users are over the message composer (see, for example, initial cursor placement). I can see it being helpful and appreciated by some (hopefully most) users while another faction will immediately want to turn off whatever we wind up adding, which is why I suggested a "View -> Option Status" toggle.
Just read your request for feedback on this bug on IRC Matthew. My suggestion would be to list the activated options in a similar way attachments are listed in the composer window: they are hidden behind the Attachment Bar, which has to be expanded if the user wants to see what is attached. This way space in the composer window is saved. I suggest you do the same here, and create the "Message Options Bar" which can expand to show active and inactive options. Instead of the tooltips with the yellow background in the mockup, I think you should use checkboxes. I think they are more effective, because checked checkboxes can communicate that the option is already activated by default, and inactive options can easily be enabled if the checkbox is checked.
Just for the record, Dave Richards suggested adding a status bar with small, possibly clickable icons indicating which options were enabled. The icon tooltips would be the option descriptions I proposed above. I pointed out it may be difficult to find a sensible icon for each option, both for the ones we have now and for any we may add in the future. There's also the problem of distinguishing between similar options, such as "PGP Sign" versus "S/MIME Sign". Not being a UI expert, I'm still going round and round with this. But here's what I think I know: - I keep coming back to the use case of accidentally sending sensitive information in an unencrypted message when the user thought it _was_ encrypted, and what we can do to help avoid that. - I decided I don't like my "View -> Option Status" toggle idea, and I still think we should have readable visual indications for those that want them. But I do recognize the importance of screen real estate and that the user may wish to hide or condense the option messages. - If the user chooses to hide the option messages, that should be persistent. They should be hidden by default in future composer windows. - I like the idea of an expander, like the attachment bar. - I think we should only show an icon or message for enabled options, to avoid visual clutter.
1) How about if the "Send" button Icon changes to a rubber-stamp icon when signing is turned on? the user may icons off, but this would be a nice visual and non-distracting change. the lack of a totally-obvious way to turn this off...I don't think it is a huge issue.
Also: The encryption examples are wrong. public/private encryption is all about the recipient key and who the owner is, the provided language in the bug description and screenshot make no sense. That is why I proposed adding it to the To: CC:, etc part of the compose window in bug 676520 Since we now have a "Signature" drop-down prominently on the compose window (or is this just me?), why not merge signing functionality into this into a clear way? -- will the conflation of footer + cryptography cause confusion?
(In reply to comment #12) > Since we now have a "Signature" drop-down prominently on the compose window (or > is this just me?), why not merge signing functionality into this into a clear > way? -- will the conflation of footer + cryptography cause confusion? The combo is for personalized signature blocks at the bottom of the message, not cryptographic signatures. Best not confuse the two.
Could icons only be put next to the signature dropdown, with a tooltip on mouse-over, and the buttons shown as menu items when clicking on these icons?
I added the options to the top toolbar, there was plenty of space. It's similar to "All Day" event toggle in an event editor. The buttons for a prioritized message and read reply are shown always, while those for sign and encrypt only after they are used for the first time. The PGP icons have added a gcr-gnupg icon as an emblem (as the name suggests, it is borrowed from gcr; without gcr icon the icons for GPG and S/MIME are the same). Created commit e804564 in evo master (3.13.8+) [1] [1] https://git.gnome.org/browse/evolution/commit/?id=e804564
*** Bug 322859 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > I added the options to the top toolbar, there was plenty of space. Attaching a screenshot is welcome - don't know if user docs are affected.
Created attachment 290368 [details] screen shot Here you are.
Thanks, Milan!
*** Bug 670826 has been marked as a duplicate of this bug. ***