Tickets :: Comment on [#10235] Email attachments on printed emails

* Your Email Address
* Spam protection	Enter the letters below: . .. . .. . . \ /\|\ \| \|\|__\| \| \/ \| \\|\__\|\| \|\__\|
Comment	>>> Please don't simply revert while we're still discussing this. It's >>> not like this breaks anything. >> >> Not to sound like a jerk - but I had originally rejected this. You >> overruled that decision and committed this. Reverting is entirely >> appropriate. We need to stay at the status quo - only until we decide >> whether we want should we add if necessary > > True. > >>> I don't buy your argument why we might include the basic headers but >>> not the attachment list. >>> 1) It's important, or at least useful, information about a message. >>> Not printing those anymore is a regression from IMP 4. >> >> I had a long discussion about this when we implemented the IFRAME >> HTML rendering. It really comes down to this: >> >> * You correctly render HTML parts. >> vs. >> * You can print the entire message. >> >> At this point, you MUST choose one or the other. In the past, HTML >> mails weren't as prevalent as they are today. Not to mention are >> rendering code and filtering code weren't all that great. >> >> But now, I would say that text/html has pretty much become the >> defacto standard. So viewing is more important than printing. >> >> Sometimes you have to make tough decisions. Yes, it is a regression >> with respect to printing messages. But it is a vast leap forward in >> the more common use case of viewing an HTML part. So I stand by this >> decision. > > I think there is consensus about this descision. > >>> 2) It's unobtrusive and won't affect many messages (probably depends >>> on how often you get messages with attachments. But then again, how >>> often do you actually print messages?) >> >> But going back to my original point: why is this attachment list >> important? How can it possibly be important to have an attachment >> list when you are only printing (and caring about) a single part? > > This question doesn't make sense to me. As you explained above we > decided to print individual parts instead of the complete message for > technical reasons. Thus the user doesn't even have a chance to print > the complete message. Of course it would make more sense to only > print the attachment list when printing the complete message, but > that's not possible. > > And to the original point: it's been requested by end users a few > times, for whatever reasons. I don't print out emails at all, so I > can't answer the question, but there seems to be a good reason for > this. And to repeat myself: I don't see a huge difference to the > basic headers that are not the headers of the MIME part either, but > the headers of the complete message. > >> When I print the portion of the message that contains the map to >> Grandma's house, I don't care that she also attached pictures of the >> cats that are going to be there to greet me when I arrive. This is >> worthless information, and cuts into the printable space available on >> that first page. > > Who are we to decide whether this is worthless information or not? If > it's your concern that some users might not want this information to > be printed with the message (I know it's not the message, but that's > how users receive it), we can make it a preference. Just like adding > the Printed By: header is configurable too. > >>> I understand the technical limitations that still keep us from >>> printing all parts, and I don't have a smart solution for this. But >>> limitations of browsers should not keep us from providing us better >>> experience for the users. Actually the opposite, we need to provide >>> users with alternative solutions if something is limiting them. >> >> Possible solutions: print as PDF; popup print screens reload after >> every printable part to load the next printable part while calling >> window.print() on each one. > > Printing all parts individually is a solution to printing complete > messages (though a rather annoying one), but not to printing an > attachment list. > > PDF is interesting but a) requires a PDF reader to be installed, and > b) doesn't work with HTML messages. > >>> The crucial point is that currently the user is not able to print the >>> whole message if it consists of multiple parts. But they don't care >>> and will print messages anyway. In 95% (if not more) of the messages, >>> there will be one single printable message part. Users don't care if >>> they are looking at a multipart message. They are happy that their >>> message will be printed (and without even knowing about that, that >>> your worked around IFRAME printing browser bugs). They don't care >>> that it's only one part of the message, because that's probably the >>> only part they see inline anyway. Heck, the printout even has the >>> message headers, they won't even notice. All that's missing is, >>> gotcha, the attachments summary they had in their old version. >> >> These are all arguments for the creation of a feature to allow >> printing of an entire message. But NONE of these arguments are >> applicable to what we currently have available: printing of a single >> message part. >> >> We can't be mixing UI elements/features just because we are lacking >> functionality. I have spent a long time in IMP 5 to remove these >> kind of decisions we made in the past - feature bloat if you will. >> Instead we need to focus on the UI as CURRENTLY implemented (not how >> we would LIKE it to be implemented). > > I agree only partially. Printing messages (as few as sense it may > make sense to us personally) is not feature bloat, but an important > feature of a mail client. > Cleaning up features and tacked-on functionality is great, and you've > done an awesome job at this with IMP 5. I can wholeheartedly > understand that you don't want stuffed "hacked" into it again. > >> As I have said multiple times in this ticket, having an attachment >> list doesn't make any sense when you look at what this UI element is >> intended to do: print a specific message part. So this patch is not >> appropriate. > > I think this approach is too academic or technical, if you want to > say so. It's correct, no question, but it's not how users are gonna > see or use this feature. They want to print their message, they see > the print icon (and in 95% of the message only one single icon), they > click on it, and they complain to their administrators that the > printout no longer contains the attachment list. If there are > multiple parts and multiple print icons, they will figure out quickly > that they have to print them individually. They will moan but work > around it, like users always do. But they cannot get their freaking > attachment list back. > > I can't believe we spend so much time and energy on such a useless > thing like printing messages. :-D I hope a single user is going to > appreciate this.
Attachment
Watch this ticket

Saved Queries