After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755418 - "Load Remote Content" info bar is too distracting
"Load Remote Content" info bar is too distracting
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.18.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2015-09-22 14:43 UTC by Bastien Nocera
Modified: 2020-08-24 10:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ios screenshot (45.18 KB, image/png)
2015-09-22 14:43 UTC, Bastien Nocera
Details

Description Bastien Nocera 2015-09-22 14:43:19 UTC
Created attachment 311878 [details]
ios screenshot

The "Remote content download had been blocked for this message." info bar is too distracting with its blue colour, and the amount of space it takes.

The same functionality in GMail, and in the iOS mailer is using the same colour chrome as the rest of the message.

GMail example:
http://www.shoutmeloud.com/wp-content/uploads/2013/12/gMail-Image-Caching-Email-marketing.gif

iOS example as attachment (although the positioning of the label at the bottom of the mail probably isn't the most judicious).
Comment 1 Milan Crha 2015-09-24 14:21:14 UTC
Thanks for a bug report.

The first part, the color, it's defined in the theme. This is the standard GtkInforbar. I agree the blue background doesn't look nice, but that's what you get when you use the theme you use.

The second part, the amount of space it takes, it's less percentage than the attached screen shot from the iOS, but more than the GMail - seems to me. It's due to the more information being shown there, with a try to explain possibilities.
Comment 2 Bastien Nocera 2015-09-24 14:33:20 UTC
You shouldn't be using an info bar here, normal chrome should do. I've added the ui-review keyword so that designers can comment as well.

(In reply to Milan Crha from comment #1)
> Thanks for a bug report.
> 
> The first part, the color, it's defined in the theme. This is the standard
> GtkInforbar. I agree the blue background doesn't look nice, but that's what
> you get when you use the theme you use.

It's the wrong widget because it's a widget that brings attention. It shouldn't.

> The second part, the amount of space it takes, it's less percentage than the
> attached screen shot from the iOS, but more than the GMail - seems to me.
> It's due to the more information being shown there, with a try to explain
> possibilities.

The iOS one is at the bottom of the mail, it doesn't encroach on my preview.
Comment 3 Milan Crha 2015-09-24 15:13:49 UTC
(In reply to Bastien Nocera from comment #2)
> It's the wrong widget because it's a widget that brings attention. It
> shouldn't.

That's question of a personal preference, I'm afraid. For me, it should bring attention, because:
a) there is some reason why the message doesn't look correct (missing images)
b) there's a hint what there can be done to make it look correct
c) the bar clearly looks like not being part of the message
Comment 4 Tim-Philipp Müller 2015-10-26 17:03:07 UTC
I find the bar quite distracting myself.

This is amplified by the fact that I only seem to be able to whitelist sites/messages for which to load remote content by default, but there doesn't seem to be an option that says 'Never load remote content from xyz', so I basically get this bar popping up (animated, with a short delay!) for most mails I receive, unless I give in and whitelist sites just to make it stop.
Comment 5 Milan Crha 2015-11-03 18:11:33 UTC
I added org.gnome.evolution.mail.notify-remote-content=true into preferences, thus users whom do not like the change can easily disable it. There's a UI in Preferences and also the drop down in the notification has "Do not show this message again" option. The idea about "never offer load" seems fine, but may make the UI too complicated, which I'd like to avoid. Thus the option was added. There are new strings added and change UI, thus only the development version has the fix.

Created commit 82eaa01 in evo master (3.19.2+)
Comment 6 Bastien Nocera 2015-11-03 18:21:33 UTC
This absolutely isn't what I requested. I need new configuration options like I need a hole in the head :(
Comment 7 Tim-Philipp Müller 2015-11-03 18:29:05 UTC
Out of curiosity: Will there still be a way to download remote content for selected mails, e.g. via the right-click context menu?

Example: I generally don't want to download remote content, but e.g. might want to print my (html) airline booking confirmation or hotel reservation or such and download the remote resources to make that show up correctly.

Or is it an always-or-never choice and if I say 'Don't show this message again' then I also won't be able to properly render html mails that I do want to see?

It looks to me like the new option doesn't really cater for this.
Comment 8 Milan Crha 2015-11-04 06:54:22 UTC
All you both claim about is the notification that the message possibly doesn't render properly, because some content is remote, which is not downloaded yet, because the user has disabled download for the remote content. There was a request to have such notification, so it's there.

You do not like it. Okay. I do not like offered options to "solve" it, thus I added the configuration option to get back to the previous behaviour, which is 'do not notify about missing remote content'. The configuration option is a lame way of dealing with you, I agree, but as I said, the other options doesn't work for me. We can fight about personal opinions, no doubt, but I'd prefer not to do it.

As this is only about the notification, which, by the way, makes it easier to manage remote content for senders/sites, there wasn't removed any functionality regarding manual remote content download. The menu item View->Load Images (Ctrl+I), is still there, regardless this notification being shown or not.
Comment 9 Bastien Nocera 2015-11-04 09:08:25 UTC
I thought Evolution was a GNOME application and you would at least listen to the GNOME designers, which is why I requested the help of designers (with the ui-review keyword). I even tried to do prior art research for you. I'm disappointed...
Comment 10 Allan Day 2015-11-06 10:35:58 UTC
(In reply to Milan Crha from comment #3)
...
> > It's the wrong widget because it's a widget that brings attention. It
> > shouldn't.
> 
> That's question of a personal preference, I'm afraid. 

No, it's really not. Design is not a matter of subjective opinion. There is good design and there is bad design. Designs can be tested to see how effective they are, and there are established techniques and principles for doing good rather than bad design.

> For me, it should
> bring attention, because:
> a) there is some reason why the message doesn't look correct (missing images)
> b) there's a hint what there can be done to make it look correct
> c) the bar clearly looks like not being part of the message

I'm glad to see some justifications here, that's a good start. There's nothing here to indicate what the level of visibility should be, though. All a and b mean is "we have some information to display": they don't indicate how or when the information should be displayed.

Reason c is wrong for a few reasons. First, because it is better to show the missing image prompt as if it is part of the message itself: this removes the distance between the prompt and where the image would appear, and correspondingly makes it easier to understand because it is in context. Second, whether or not you download the image will typically be dependent on the subject and sender of the message. By placing the info bar above the message header and making it so prominent, you are distracting from the information the user needs to see first. In effect you're screwing with the natural order in which the view will be read.

Something closer to what Gmail does seems superior for these reasons.

I don't understand why an option was added here: who do you expect to use this hidden gsettings key? How do you expect them to find it?
Comment 11 Milan Crha 2015-11-09 08:18:14 UTC
(In reply to Allan Day from comment #10)
> Second, whether or not you download the image...

Even I mentioned it as "missing image", in practice it's not only about images, it can be anything what the user placed inline as a remote reference, including CSS styles, thus the message can completely look odd until the CSS is downloaded.

I partly agree with the rest. I only prefer to be able to distinguish between what the sender wrote and what the application added to the message on its own. Placing the information bar below the headers and making it look similar like the rest of the message would make things harder for me.

As I wrote in bug #236994 comment #3, I made it close to what Thunderbird does. I guess they have also designers, and they are not totally off.

> I don't understand why an option was added here: who do you expect to use
> this hidden gsettings key? How do you expect them to find it?

It's not hidden, it's in Edit->Preferences->Mail Preferences->HTML Messages tab and in the dropdown of that notice itself.
Comment 12 Bastien Nocera 2015-11-09 15:45:46 UTC
There's plenty of white space on the right of the header information, in the preview pane, where a button to load remote images (and other remote data) could be shown, perhaps even the same button that was in the info bar.
Comment 13 Milan Crha 2015-11-09 17:16:18 UTC
Not always. The place is used for sender's photo, if available. There also couldn't be much of the descriptive text as in the info bar (I hope it is a bit descriptive, at least). Or do you all think that having there a button "Load remote content" with a drop down arrow would be enough for average users to understand what that is good for without any further clarification?

Do not take me wrong, I'm willing to change this, even get rid of the new (useless) option, I only do not see any good solution right now.
Comment 14 Bastien Nocera 2015-11-18 16:48:06 UTC
(In reply to Milan Crha from comment #13)
> Not always. The place is used for sender's photo, if available.

Just how many emails that use remote images also have photos added through gravatar or in the contacts? Genuinely curious.

> There also
> couldn't be much of the descriptive text as in the info bar (I hope it is a
> bit descriptive, at least). Or do you all think that having there a button
> "Load remote content" with a drop down arrow would be enough for average
> users to understand what that is good for without any further clarification?

Given that you'd only see this drop-down if you disabled loading remote images (it's enabled by default, right?) then I don't think it needs much more information than what's currently in the button + drop-down menu.

Do we reopen this bug, or start a new one?
Comment 15 Milan Crha 2015-11-19 05:42:19 UTC
(In reply to Bastien Nocera from comment #14)
> Just how many emails that use remote images also have photos added through
> gravatar or in the contacts?

... or in the Face header.

> Genuinely curious.

I do not have any idea how real users use the client and what they send. There are rumours that a significant part likes HTML, while I do not that much.

> Given that you'd only see this drop-down if you disabled loading remote
> images (it's enabled by default, right?)

Nope, it's disabled by default - the safer option.

> Do we reopen this bug, or start a new one?

We can stay here. If I'd do anything here, I revert the previous change (added option) first.
Comment 16 Milan Crha 2015-11-19 05:49:39 UTC
To summarize, the idea is to drop the info bar about not-loaded remote content and replace it with the simple combo [ Load remote content | v ] combo box without any explanation what it is good for and why it is shown, placed on the right (or the left in RTL) of the headers (which can be collapsed (one line only) or expanded).

Tomas, the headers are part of an HTML page. Would that be a problem in the webkit2 port, considering they dropped Gtk plugins in WebKit2? Maybe using a real HTML combo box with certain DOM callbacks? Such DOM callbacks might be on the extension side (the other process), right?
Comment 17 Tomas Popela 2015-11-19 07:42:40 UTC
(In reply to Milan Crha from comment #16)
> Tomas, the headers are part of an HTML page. Would that be a problem in the
> webkit2 port, considering they dropped Gtk plugins in WebKit2? Maybe using a
> real HTML combo box with certain DOM callbacks? Such DOM callbacks might be
> on the extension side (the other process), right?

Exactly as you are saying. Also we should not implement it as a Gtk widget even for the current WebKit1 port, to save some work later.
Comment 18 Milan Crha 2019-10-09 13:33:22 UTC
Finally made this happen by adding a dialog-information icon on the very right of the headers, which has a tooltip and when clicked, then it opens a popover with the information like in the info bar and with the options what to do. I left there the option to not show it again, even though it might be useless now.

Created commit [1] in evo master (3.35.1+)

[1] https://gitlab.gnome.org/GNOME/evolution/commit/7c7eb401f2
Comment 19 Milan Crha 2020-05-18 07:25:06 UTC
Just for the record, there seem to be more people not liking the change than those concerned about the space.

Space concern:
  https://gitlab.gnome.org/GNOME/evolution/-/issues/852

Against (it has duplicates, though also the above one):
  https://gitlab.gnome.org/GNOME/evolution/-/issues/847

but also voices against this on the evolution-list mailing list.
Comment 20 Bastien Nocera 2020-08-03 08:53:23 UTC
(In reply to Milan Crha from comment #18)
> Finally made this happen by adding a dialog-information icon on the very
> right of the headers, which has a tooltip and when clicked, then it opens a
> popover with the information like in the info bar and with the options what
> to do. I left there the option to not show it again, even though it might be
> useless now.

I don't understand why an icon that has no connection to the problem at hand was chosen rather than text. At least it fixed the problem of distracting, I never even noticed it, and used Ctrl+I to load the images.
Comment 21 Milan Crha 2020-08-24 10:26:20 UTC
It felt appropriate to me, but it can be just my personal opinion, which can be right, wrong or a bit of both.