Re: [OT] KMail - forwarding issues
On Sun, 31 Oct 2010 15:40:49 -0500, Boyd Stephen Smith Jr. wrote:
> In <[🔎] pan.2010.10.31.19.35.06@gmail.com>, Camaleón wrote:
>>It is called "evolution".
>>
>>The first hypertext applications were not very dynamic, I'd say, just
>>text and some links to jump to. Just look around now what the web has to
>>offer.
>
> Yes, because HTML (in particular) was designed with that in mind.
> Gluing together of disparate resources in a relatively full-featured
> client.
>
> Email was NOT designed this way. It took decades before it could handle
> attachments sanely. MUAs should not be expected to even be ABLE to
> fetch resources that are outside of the current message. There are
> proposals I've seen for using URIs in the HTML that resolve to other
> parts of the same MIME structure, but they are not followed by (m)any
> MUAs, particularly composers, and they all seemed a bit fragile as I was
> reading them.
A html editor can be a very simple piece of software as html markup
language is. It has to follow a few of well-defined and static rules and
nothing more.
I am not saying that having a full-featured html editor (like Bluefish)
embedded into Kmail is the path to go (a MUA is not an application for
designing dynamic web content) but it should be just fine with basic html
4.01 syntax at least for displaying/dealing with images, tables, basic
css style and text formatting. Nothing more, no need to add extra
capabilities such javascript or flash interpreter, no need for adding
extra addons, just a basic editing that goes beyond the plain text.
In fact, Kmail currently allows displaying html content and perform basic
html editing and that doesn't seem that bad.
>>I can understand people dislike that things, but forcing their own POV
>>to the rest of the users is not a fair approach. In that reasoning, we
>>could still stay with "us-ascii" encoding and ditch "utf-8", but
>>nowadays I wouldn't find it quite appropiate.
>
> Use a different, more appropriate, medium if you want to use HTML. The
> push / send model is not appropriate for the gluing together of
> disparate resources, in particular untrusted resources.
You are talking here about external content (like linked or embedded
images) but an e-mail client that supports html is useful for more than
that.
Untrusted sources can be also blocked as Icedove does. In fact, Kmail
also does the same way, allowing the user whether load or don't load
images coming from external sites or even displaying (by default) html
formatted messages as plain text.
That is not a valid argument for Kmail cannot forward or reply to html
formatted e-mails while preserving the whole sctructure of the message.
> When using the web, you are using a pull / request model. In this case,
> server dictates the terms. The UA must accept and process whatever the
> server deigns to deliver as part of the request, and the user must seek
> out a UA with the right features in order to satisfy their needs.
>
> In this model, "evolution" moves quickly, since new features are adopted
> by a users in order to handle response from more servers.
You will still facing "client side" programming issues. Not all browsers
renders the same the different versions of javascript/DOM/CSS3 (Ajax) so
you still heavily depend on the client and its capabilities.
> When using email, you are using a push / send model. In this case, the
> recipient dictates the terms. The MUA must only create and send data
> that the recipient is willing to accept or the effort is wasted, and the
> user must seek out a MUA that can reach the most recipients. (In a
> support context, more recipients = more replies = more useful replies =
> better support. In a marketing / community context, more recipients =
> more eyes = more inquiries = more sales / members.)
>
> In this model, "evolution" moves slowly, since new features are avoided
> by users in order to reach the most recipients.
>
> I have descent bandwidth, to doing a reasonable multipart/alternative
> message will reach me. You send in text/html and your message just goes
> in the round file. Others don't have the bandwidth to waste / spend;
> multipart/alternative messages reach their round file. Still others
> will accept all 3 forms. If you want the most people to see your
> message, you'll use text/plain.
Again, that reasoning has nothing to do with html messages nor
technicalities, you are talking about what are your own preferences. I
receive text messages bigger in size than html formatted e-mails. It all
depends on the ability of the sender in making well designed e-mails (of
course, it also depends on having a good the e-mail client html editor).
In fact, there is RFC 1896 that addressed (on the earlier Internet days)
the concerns of formatted text in e-mails.
>>> Paradox of choice. Fewer options is easier to understand. If the new
>>> feature is not the default, how will we show it off; if the new
>>> feature is the default, the existing user base will complain.
>>
>>But I'm not talking about "defaulting" KMail to html e-mails. Plain text
>>e-mails can be defauult choice, I have no objections to that. People is
>>smart enough to switch over text/html if properly indicated inside Kmail
>>UI (an actually I know it is) and even if the user cannot find it,
>>he/she can always ask in mailing lists or forums on how to change it.
>
> That was 3 reasons, not 1. You still haven't addressed "Paradox of
> choice" (a practical, documented usability problem) or "Fewer options is
> easier to understand".
If you are concerned about that "usability problem" then ask the users
what would they prefer and what would be more confortable for them. Do
not make the error of just think for them.
Again, Kmail does currently have support for basic html editing and e-
mail creation, so I still fail to see the problem of just "improving" a
feature that is currently available.
> I must have snipped too much, but you mentioned UTF-8 vs. US-ASCII.
> UTF-8 doesn't replace US-ASCII, the replaces dozens of different ways to
> handle bytes that are not in US-ASCII. Using UTF-8 rarely reduces the
> number of people your message is seen by. If it is all US-ASCII
> character, then the UTF-8 encoding is a no-op and everyone that could
> read it before can still read it. If it is not all US-ASCII, then
> you've traded users of specific other encodings for users that can read
> UTF-8. In certain forums, it *still* might be best to use an encoding
> other that UTF-8, but not on a Debian forum. (Since UTF-8 is so well
> supporting in Debian oldstable and above.)
You are not losing audience by using html e-mails. Even Mutt have the
proper tools to handle that (meaning that text based MUAs can just launch
an external program to properly render the e-mail).
Moreover, Icedove has an option to send html formatted e-mails along with
plain text, just plain text or just html. The sender can choose the
appropiate format based on his/her user target.
Greetings,
--
Camaleón
Reply to: