Re: [OT] KMail - forwarding issues
On Mon, 01 Nov 2010 15:00:22 -0500, Boyd Stephen Smith Jr. wrote: > On Monday 01 November 2010 14:34:10 Camaleón wrote: >> On Mon, 01 Nov 2010 14:14:48 -0500, Boyd Stephen Smith Jr. wrote: >> > Users didn't want UNIX or C when it was invented. Users didn't want >> > the GUI when it was invented. >> >> Are you basing your argument in stating that all users in the world are >> always wrong? > > No. "No" is neither a good argument :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.01.20.16...@gmail.com
Re: [OT] KMail - forwarding issues
On Monday 01 November 2010 14:34:10 Camaleón wrote: > On Mon, 01 Nov 2010 14:14:48 -0500, Boyd Stephen Smith Jr. wrote: > > Users didn't want UNIX or C when it was invented. Users didn't want the > > GUI when it was invented. > > Are you basing your argument in stating that all users in the world are > always wrong? No. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] KMail - forwarding issues
On Mon, 01 Nov 2010 14:14:48 -0500, Boyd Stephen Smith Jr. wrote: > In , Camaleón wrote: >>> Studies and experience have shown time and time again that users >>> *don't know* what they want. Henry Ford once said: "If I asked my >>> customers what they wanted, they would have said 'A faster horse.'" >>> It is an unfortunate truth, but usability problems are not solved by >>> soliciting user input. >> >>Sorry but I have to disagree. > > Well, then you are wrong. There a more than a decade of studies showing > you are wrong. I'll let you find them yourself. Sigh. Then I'll have to live with that along with my need of having to manage html e-mails in a world that cannot understand me :-) > Users didn't want UNIX or C when it was invented. Users didn't want the > GUI when it was invented. Are you basing your argument in stating that all users in the world are always wrong? Ouch, I wouldn't like to be in the marketing area nor in usability studies field, what a waste of time... You are not losing audience by using html e-mails. >>> Yes you are. There is a non-zero number of people on *this* mailing >>> list that simply discard mails containing an HTML part. >> >>Again, that is a _personal_ decision, not a technical one. I have >>nothing against personal views... just they're personal. > > My point still stands. If you use HTML mail, you will lose readers. > This is a bad thing. And so is mine. Kmail will lose users that need that feature which now is provided in a very limited state. >>Any e-mail client out there can handle html formatting, so if someone >>rejects e-mails formatted in that way is not because their MUA cannot >>manage them. > > There are a number of client out there that, absent some custom > configuration, render the "raw" HTML code. This is virtually unreadable > for most people, especially considering the poor quality HTML produced > by most Hey, it's html and one of its benefits is precisely that is "plain text" and so "readable" with just the most primitive text editor. You can even save the raw e-mail message and then render it within the web browser of your choice (yep, lynx included). Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.01.19.34...@gmail.com
Re: [OT] KMail - forwarding issues
In , Camaleón wrote: >On Mon, 01 Nov 2010 02:42:37 -0500, Boyd Stephen Smith Jr. wrote: >> In , Camaleón wrote: >(...) > >>>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. >>> >> Studies and experience have shown time and time again that users *don't >> know* what they want. Henry Ford once said: "If I asked my customers >> what they wanted, they would have said 'A faster horse.'" It is an >> unfortunate truth, but usability problems are not solved by soliciting >> user input. > >Sorry but I have to disagree. Well, then you are wrong. There a more than a decade of studies showing you are wrong. I'll let you find them yourself. Users didn't want UNIX or C when it was invented. Users didn't want the GUI when it was invented. >>>You are not losing audience by using html e-mails. >>> >> Yes you are. There is a non-zero number of people on *this* mailing >> list that simply discard mails containing an HTML part. > >Again, that is a _personal_ decision, not a technical one. I have nothing >against personal views... just they're personal. My point still stands. If you use HTML mail, you will lose readers. This is a bad thing. >Any e-mail client out there can handle html formatting, so if someone >rejects e-mails formatted in that way is not because their MUA cannot >manage them. There are a number of client out there that, absent some custom configuration, render the "raw" HTML code. This is virtually unreadable for most people, especially considering the poor quality HTML produced by most -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] KMail - forwarding issues
On Mon, 01 Nov 2010 02:42:37 -0500, Boyd Stephen Smith Jr. wrote: > In , Camaleón wrote: (...) >>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. > > Studies and experience have shown time and time again that users *don't > know* what they want. Henry Ford once said: "If I asked my customers > what they wanted, they would have said 'A faster horse.'" It is an > unfortunate truth, but usability problems are not solved by soliciting > user input. Sorry but I have to disagree. First, because I know what I want :-) And second, because automotive market is not the best sample to compare with computer industry... if computers had followed the same path, we were still would be using "punch cards". >>You are not losing audience by using html e-mails. > > Yes you are. There is a non-zero number of people on *this* mailing > list that simply discard mails containing an HTML part. Again, that is a _personal_ decision, not a technical one. I have nothing against personal views... just they're personal. Any e-mail client out there can handle html formatting, so if someone rejects e-mails formatted in that way is not because their MUA cannot manage them. And I'm not talking here about personal decisions, every one has their own needs and feelings on this matter. This is about the lack of options we currently have for Kmail when it comes to html e-mails. You don't want html in your e-mails? Perfect, don't use it. But if you do not provide such option for people who need it, you'll lose your users. It's that simple. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.11.01.11.10...@gmail.com
Re: [OT] KMail - forwarding issues
Dne, 01. 11. 2010 08:42:37 je Boyd Stephen Smith Jr. napisal(a): Studies and experience have shown time and time again that users *don't know* what they want. Henry Ford once said: "If I asked my customers what they wanted, they would have said 'A faster horse.'" It is an unfortunate truth, but usability problems are not solved by soliciting user input. My point exactly. In addition, I think that, as a rule, users who *could* give you an informed feedback, are a tiny minority, which gets overwhelmed by the feedbacks of the "uninformed masses". So, in theory, you *could* get tangible help out of user input, but would have to know how to weed out noise from insightful input. As it is, the less insightful, the less constructive, the less informed feedback wins -- by virtue of sheer numbers. In my view, that's not a good developing model, in fact it's *counter*productive. Fortunately, no developers in their right mind listen "blindly" to anything the user base says; developers don't just "develop", they also weed out what to implement from what to just mark as WON'TFIX. And that's a Good Thing, when done well. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288602179.1121...@compax
Re: [OT] KMail - forwarding issues
In , Camaleón wrote: >On Sun, 31 Oct 2010 15:40:49 -0500, Boyd Stephen Smith Jr. wrote: >> 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. Yes, but the user wants something from your service, so you dictate the terms of communication. If the user has multiple choices for satisfying that want, you can compete on (lack of) features, but it is ultimately the servers that make the decision on what the user has to put up with. >> 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 am talking about which side dictates the terms of the exchange. When sending a email you (usual) goal is to get as many readers as possible. Using features their UAs don't understand or that the recipients themselves find distasteful reduces you readership. >> 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. Studies and experience have shown time and time again that users *don't know* what they want. Henry Ford once said: "If I asked my customers what they wanted, they would have said 'A faster horse.'" It is an unfortunate truth, but usability problems are not solved by soliciting user input. >You are not losing audience by using html e-mails. Yes you are. There is a non-zero number of people on *this* mailing list that simply discard mails containing an HTML part. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] KMail - forwarding issues
On Sun, 31 Oct 2010 15:40:49 -0500, Boyd Stephen Smith Jr. wrote: > In , 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
Re: [OT] KMail - forwarding issues
On 10/31/2010 08:51 AM, Camaleón wrote: [snip] Come on, we cannot be so hypocrite. In no way html is a bad thing "per se", it is an standard, it has it uses and people need that feature. 2400 people need that feature. In business, people *constantly* use html mail in Outlook/Exchange and it's *stupendously useful* for numbering/bulleting, highlighting, pasting images, etc, etc. -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccde084.70...@cox.net
Re: [OT] KMail - forwarding issues
On 10/31/2010 08:14 AM, Klistvud wrote: Dne, 31. 10. 2010 12:02:39 je Camaleón napisal(a): On Sun, 31 Oct 2010 10:49:24 +, Lisi wrote: > On Sunday 31 October 2010 10:32:24 Camaleón wrote: >> I don't see how a "lack" (meaning, "inability of choice") can be a good >> feature ;-( I don't think you can directly equate "choice" to "feature" just like that. Not letting kids wield guns, Kids wield guns on an extraordinarily frequent basis w/o injury to anything but the intended non-human target (milk jug, deer, squirrel, groundhog, duck, alligator, etc, etc). -- Seek truth from facts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ccdde09.3020...@cox.net
Re: [OT] KMail - forwarding issues
In , Camaleón wrote: >On Sun, 31 Oct 2010 13:51:04 -0500, Boyd Stephen Smith Jr. wrote: >> In , Camaleón wrote: >>>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote: Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): > I don't know how can you equate all that stuff with having html > e-mail unsless you also avoid using Internet (websites use html and > not plain text and we are all happy with that). >> >> The web was founded on text/html. Email was founded on text/plain. The >> web is a pull / request model. Email is a push / send model. The web >> operates through multiple linked requests. Email expects everything >> inside a single message. > >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. >> The reason people dislike HTML email is because email is a different >> type of medium, for which HTML is inappropriate. > >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. 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. 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. I was not equating anything with anything, I was just trying to make a distinction about features not always being choices and vice versa; and about features not always making us better off. >>> >>>Sorry, but I fail to see how "adding" new options can be "bad" for >>>users. >>> >> 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". 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*
Re: [OT] KMail - forwarding issues
On Sun, 31 Oct 2010 13:51:04 -0500, Boyd Stephen Smith Jr. wrote: > In , Camaleón wrote: >>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote: >>> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): I don't know how can you equate all that stuff with having html e-mail unsless you also avoid using Internet (websites use html and not plain text and we are all happy with that). > > The web was founded on text/html. Email was founded on text/plain. The > web is a pull / request model. Email is a push / send model. The web > operates through multiple linked requests. Email expects everything > inside a single message. 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. > The reason people dislike HTML email is because email is a different > type of medium, for which HTML is inappropriate. 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. >>> I was not equating anything with anything, I was just trying to make a >>> distinction about features not always being choices and vice versa; >>> and about features not always making us better off. >> >>Care to tell me just one thing that would make having a full featured >>html formatting editor embedded in kmail harm users? >> >>Sorry, but I fail to see how "adding" new options can be "bad" for >>users. > > 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. >>Will it prevent user for using plain text e-mails as they were used to? >>No, it won't, users can still use their MUA in the way they prefer. > > Depends. Other clients in the past have grown test/html support in ways > that make it very difficult, if not impossible, to write well-formed > text/plain emails using them. I would call that a bug, sir (and a big one), and being a bug is something that should be fixed :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.10.31.19.35...@gmail.com
Re: [OT] KMail - forwarding issues
In , Camaleón wrote: >On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote: >> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): >>> I don't know how can you equate all that stuff with having html e-mail >>> unsless you also avoid using Internet (websites use html and not plain >>> text and we are all happy with that). The web was founded on text/html. Email was founded on text/plain. The web is a pull / request model. Email is a push / send model. The web operates through multiple linked requests. Email expects everything inside a single message. The reason people dislike HTML email is because email is a different type of medium, for which HTML is inappropriate. >> I was not equating anything with anything, I was just trying to make a >> distinction about features not always being choices and vice versa; and >> about features not always making us better off. > >Care to tell me just one thing that would make having a full featured >html formatting editor embedded in kmail harm users? > >Sorry, but I fail to see how "adding" new options can be "bad" for users. 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. >Will it prevent user for using plain text e-mails as they were used to? >No, it won't, users can still use their MUA in the way they prefer. Depends. Other clients in the past have grown test/html support in ways that make it very difficult, if not impossible, to write well-formed text/plain emails using them. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] KMail - forwarding issues
On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote: > Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): >> I don't know how can you equate all that stuff with having html e-mail >> unsless you also avoid using Internet (websites use html and not plain >> text and we are all happy with that). > > I was not equating anything with anything, I was just trying to make a > distinction about features not always being choices and vice versa; and > about features not always making us better off. Care to tell me just one thing that would make having a full featured html formatting editor embedded in kmail harm users? Sorry, but I fail to see how "adding" new options can be "bad" for users. Will it make Kmail package breaks? No, I don't think so. Will it make Kmail package increses its size? Maybe some megabytes, not a big deal. Will it prevent user for using plain text e-mails as they were used to? No, it won't, users can still use their MUA in the way they prefer. So, what is the damage this will make? I can't name it. >> People is free to choose whatever they want because they have the >> capability to do it so, that's the beatiful of freedom. >> >> > With freedom should come responsibility. However, that doesn't seem to > be the case. If I take a look around me -- of course, it may just be me > -- I see that, more often than not, people make choices for the worse. Let people learn from their errors. Forcing users to act as "they should" will only make they reject to do it that way. It's a psychological fact: the more interest you have in people behave in a concrete manner, the more interest they'll have in acting the opposite. > Problem is, those poor choices of the so-called "majority" have > repercussions on all of us. In the end, I'm forced to endure HTML mail, > although I may despise it. I'm forced to endure flash although I may > despise it. If I want to be able to play music on a mobile phone or a > portable player, I'm forced to either use the patent-encumbered mp3 > format or nothing -- open formats are not supported, or only > exceptionally. That must be you, sir. I'm not enforced to anything of this. I can browse the web with lynx or I can use an addon to avoid loading javascript, pop- ups or flash animations. You like flash? You got it. You don't like, you can avoid it without any problem. Todays browsers can handle that for you in an easy manner. > If I want to watch family photos on my home DVD recorder, > they have to be in the royalty-encumbered jpg format -- again, open > formats are rarely supported. Gosh, even for just *taking* a family > photo I'll have a hard time finding a camera that doesn't use > patent-encumbered formats! If I want to buy a laptop that is at least > half-compatible with a Free OS, I must go to great lengths to check in > advance that all components will work at all, because the wise majority > is quite content with it working in Windows and couldn't care less. And > it's not just a matter of abstract principles, sometimes it interferes > with my life quite directly. For example, if I want to exchange document > files with my clients in order to make my living -- they require I use > the proprietary Word .doc format. They've obviously never even heard of > .odt and the like. All these, and many other, choices are being thrust > upon me on a daily basis by the "savvy majority", and they are all poor > choices in my view. That seems to be a bit of rant again many things that have nothing to do with the issue we are talking about. Ranting is free, though. I think that a bit of ranting does not hurt from time to time, but in the end, I prefer acting and helping users/developers to fix things they do not like or they want to improve :-) >> Your are messing up things. Nobody is telling that you have to use html >> e- >> mails, I am telling that having such option will not prevent users for >> still using text e-mails. >> >> In fact, you will still receive html spam and viruses regardless the >> MUA >> you use and regardless its capabilities, so your argument is bit of no- >> sense. >> >> > True, but if you think about what made HTML spam and viruses possible in > the first place, you'll come to the conclusion that it was the > introduction of HTML mail. I don't have -right now- any statistics about this, but IIRC, there is a higher percentage of spam using plain text e-mail rather than html format, because users avoid opening html messages (antivirus companies and anti-malware campaings tell them to do so) so they are very cautelous with these e-mails but have no problem with opening plain text ones. > It was the bane of the "feature-driven > design". It was the "hey, why-not" attitude. Many of us never wanted it. If you don't want to use something, then do not use it but let other users can make use of it if they want :-) > I was on dial-up at the time and sure as hell didn't want it. I thought > that text-only mail standard was lea
Re: [OT] KMail - forwarding issues
Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a): On Sun, 31 Oct 2010 14:14:12 +0100, Klistvud wrote: > > I don't think you can directly equate "choice" to "feature" just like > that. Not letting kids wield guns, or prostitute themselves, or work in > sweatshops, are "features" although actually limiting their "ability of > choice". Not allowing people to drive cars before taking a driver's > license, although limiting people's "choice", is likewise arguably a > "feature". I don't know how can you equate all that stuff with having html e-mail unsless you also avoid using Internet (websites use html and not plain text and we are all happy with that). I was not equating anything with anything, I was just trying to make a distinction about features not always being choices and vice versa; and about features not always making us better off. Come on, we cannot be so hypocrite. We could at least try ... ;) I think you are missing the point completely. Now you're beginning to sound exactly as my wife ... ;) People is free to choose whatever they want because they have the capability to do it so, that's the beatiful of freedom. With freedom should come responsibility. However, that doesn't seem to be the case. If I take a look around me -- of course, it may just be me -- I see that, more often than not, people make choices for the worse. Problem is, those poor choices of the so-called "majority" have repercussions on all of us. In the end, I'm forced to endure HTML mail, although I may despise it. I'm forced to endure flash although I may despise it. If I want to be able to play music on a mobile phone or a portable player, I'm forced to either use the patent-encumbered mp3 format or nothing -- open formats are not supported, or only exceptionally. If I want to watch family photos on my home DVD recorder, they have to be in the royalty-encumbered jpg format -- again, open formats are rarely supported. Gosh, even for just *taking* a family photo I'll have a hard time finding a camera that doesn't use patent-encumbered formats! If I want to buy a laptop that is at least half-compatible with a Free OS, I must go to great lengths to check in advance that all components will work at all, because the wise majority is quite content with it working in Windows and couldn't care less. And it's not just a matter of abstract principles, sometimes it interferes with my life quite directly. For example, if I want to exchange document files with my clients in order to make my living -- they require I use the proprietary Word .doc format. They've obviously never even heard of .odt and the like. All these, and many other, choices are being thrust upon me on a daily basis by the "savvy majority", and they are all poor choices in my view. But if you are encouraging users to drop Kmail just because of that, well, that is your POV. I prefer to help to correct those things that I think are wrong. I don't encourage users to do anything. I am just expounding the 2¢ worth of my POV. Your are messing up things. Nobody is telling that you have to use html e- mails, I am telling that having such option will not prevent users for still using text e-mails. In fact, you will still receive html spam and viruses regardless the MUA you use and regardless its capabilities, so your argument is bit of no- sense. True, but if you think about what made HTML spam and viruses possible in the first place, you'll come to the conclusion that it was the introduction of HTML mail. It was the bane of the "feature-driven design". It was the "hey, why-not" attitude. Many of us never wanted it. I was on dial-up at the time and sure as hell didn't want it. I thought that text-only mail standard was lean, bandwidth-efficient, fast and lightweight, and something the Internet Consortium (or whoever invented it) could really be proud of. Why ruin it? Well, the savvy majority decided for us all. Now, we have to endure HTML spam and viruses just like all those who made the wise decision to introduce HTML "features" into e-mail. Well, thanks for nothing. P.S. Nothing of the above is aimed at Kmail specifically. Kmail is the greatest mail client I've ever used, more complete, more intuitive, and more stable than Balsa which I'm using now. I've only dropped it because I switched to Gnome and don't want to burden my system with any KDE libraries. I've used Kmail for a year or so and never even noticed whether it had HTML support or no -- just goes to show how much I needed it. -- Cheerio, Klistvud http://bufferoverflow.tiddlyspot.com Certifiable Loonix User #481801 Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288540265.1121...@compa
Re: [OT] KMail - forwarding issues
On Sun, 31 Oct 2010 14:14:12 +0100, Klistvud wrote: > Dne, 31. 10. 2010 12:02:39 je Camaleón napisal(a): >> >> I don't see how a "lack" (meaning, "inability of choice") can be a >> >> good feature ;-( > > I don't think you can directly equate "choice" to "feature" just like > that. Not letting kids wield guns, or prostitute themselves, or work in > sweatshops, are "features" although actually limiting their "ability of > choice". Not allowing people to drive cars before taking a driver's > license, although limiting people's "choice", is likewise arguably a > "feature". I don't know how can you equate all that stuff with having html e-mail unsless you also avoid using Internet (websites use html and not plain text and we are all happy with that). Come on, we cannot be so hypocrite. In no way html is a bad thing "per se", it is an standard, it has it uses and people need that feature. 2400 people need that feature. You can start ignoring people wishes but then you can forget that people fill bugs for another things, they'll just search another alternatives to kmail or even KDE. > Now, something like HTML mail is either a feature or it is not. Steering > issues about "features" into issues of "liberty to choose" is, in my > view, counterproductive. If we begin talking about the "liberty to > choose", we'll soon have to install bumps in our roads because of > reckless people who "choose" to drive like lethal bullets, or will have > to endure excruciating check-ups at airports because of people who > "choose" to use airplanes for something else than simply getting from > one place to another, or will have to endure hefty, painfully slow > flash-infested mail... Oh, we already do all that? I rest my case. I think you are missing the point completely. >> I wouldn't call it "choice" when you are forced to drop an e-mail >> client >> you like just because it lack one feature that it should be there (it's >> a >> GUI e-mail client, it allows creating html e-mails, so... why not >> having >> a full featured html editor that allows forwarding/replying while >> keeping >> the original format?). > > That's precisely the problem. Approaching something on a why-not basis > instead of on a what-the-heck-for basis. Hey, why not make YAMC (yet > another mail client), basically re-inventing the wheel, instead of > joining the developers of a pre-existing mail client, and helping it > become 10x as fast, 100x as lightweight and 1000x as robust as all other > mail clients taken together? Hey, why not drop a stable, popular and > beloved DE such as KDE3 and, just for the heck of it, start a hazy, > bug-ridden, pre-production experiment called KDE4? Hey, why not have a > welcome page on our web site made of a *huge* java, or flash > application, stuffed full with blinking eye-sores and background music > and all imaginable bandwidth hogs, just to basically say "Welcome to our > site"? Hey, why encode e-mails as TEXT? It's so damn last-year, let's > encode it as MPEG-1 instead, or RealMedia -- or, hey -- as uncompressed > video! Yep, why not? Man, we could make the "Subject:" field alone take > up 125 MB if we just try hard enough! There is no need to reinvent nothing. Kmail has support for html e-mail formatting, it just lacks some features to properly handle that format. A bug or a feature... I do not care. I don't think Mutt needs to be able to handle hmtl e-mails because is not a MUA designed for that purpose. But Kmail _is_ and has a very poor support for html. To be fair, if Kmail DDs do not want html, it would be better to dropt it at all. >> Besides, there are "thounsand" users wanting such feature. > > Sad, isn't it? Very sad. That behaviour could mean: 1/ Kmail DDs are not able to add that feature because they just do not know how to make it possible. 2/ Kmail DDs are completely ignoring their users which does not sound good, either. >> I fail to see a direct relation between this example and Kmail html >> issue, because you cannot go and turn off the light (you are not >> allowed >> to do it so, but police) but you can still have plain text e-mail >> forwarding _or_ html e-mail forwarding: here the choice is fully yours. > > Sounds great. Except, the choice is fully yours. Of course... so that I dropped KDE. Do you think that is the right way for open source projects? Coomunication should flow from both extremes, users <-> devels. > Which, given that, > generally, 90% of the people will choose Windows over GNU/Linux, Word > .doc format over open document standards, royalty-ridden multimedia > formats over open ones, vendor lock-in over open hardware/drivers, or > even super-sized hamburgers over healthy foods, can be a problem in > itself. People is free to choose whatever they want because they have the capability to do it so, that's the beatiful of freedom. But if you are encouraging users to drop Kmail just because of that, well, that is your POV. I prefer to help to correct th
Re: [OT] KMail - forwarding issues
On 10/31/2010 09:14 AM, Klistvud wrote: > Unfortunately, many of us have that path quite simply *thrust upon > us*. I wouldn't call that a choice by any stretch of the imagination. > Ever tried updating your mail over a tethered UMTS phone because your > DSL line just died or you're in the wild somewhere, with only your > laptop and your GSM phone? It's an enlightening experience, at a flaky > 2-3 kps. Particularly when you realize that the bulk of that > 45-minutes download that has drained both your battery and your > pre-paid GSM account, has been taken by a couple of unsolicited > multimedia-infested HTML mails ... can't you tell your mail client to either: 1. not download html emails, headers only 2. not download ANY email with attachments 3. not download any email over Xkb I feel your pain.. I was just in a hotel all week, where the dsl connection was: 1. flakey & prone to disconnect 2. SLOW... and of course my wifes Windows box on Tuesday wanted to download a 111MB virus program update and 11 Windows updates, and Thunderbird wanted to update to 3.1.6 !!! -- Paul Cartwright Registered Linux user # 367800
Re: [OT] KMail - forwarding issues
Dne, 31. 10. 2010 12:02:39 je Camaleón napisal(a): On Sun, 31 Oct 2010 10:49:24 +, Lisi wrote: > On Sunday 31 October 2010 10:32:24 Camaleón wrote: >> I don't see how a "lack" (meaning, "inability of choice") can be a good >> feature ;-( I don't think you can directly equate "choice" to "feature" just like that. Not letting kids wield guns, or prostitute themselves, or work in sweatshops, are "features" although actually limiting their "ability of choice". Not allowing people to drive cars before taking a driver's license, although limiting people's "choice", is likewise arguably a "feature". Now, something like HTML mail is either a feature or it is not. Steering issues about "features" into issues of "liberty to choose" is, in my view, counterproductive. If we begin talking about the "liberty to choose", we'll soon have to install bumps in our roads because of reckless people who "choose" to drive like lethal bullets, or will have to endure excruciating check-ups at airports because of people who "choose" to use airplanes for something else than simply getting from one place to another, or will have to endure hefty, painfully slow flash-infested mail... Oh, we already do all that? I rest my case. > > There _is_ choice - there are loads of email clients and most of them > have inline pictures. I wouldn't call it "choice" when you are forced to drop an e-mail client you like just because it lack one feature that it should be there (it's a GUI e-mail client, it allows creating html e-mails, so... why not having a full featured html editor that allows forwarding/replying while keeping the original format?). That's precisely the problem. Approaching something on a why-not basis instead of on a what-the-heck-for basis. Hey, why not make YAMC (yet another mail client), basically re-inventing the wheel, instead of joining the developers of a pre-existing mail client, and helping it become 10x as fast, 100x as lightweight and 1000x as robust as all other mail clients taken together? Hey, why not drop a stable, popular and beloved DE such as KDE3 and, just for the heck of it, start a hazy, bug-ridden, pre-production experiment called KDE4? Hey, why not have a welcome page on our web site made of a *huge* java, or flash application, stuffed full with blinking eye-sores and background music and all imaginable bandwidth hogs, just to basically say "Welcome to our site"? Hey, why encode e-mails as TEXT? It's so damn last-year, let's encode it as MPEG-1 instead, or RealMedia -- or, hey -- as uncompressed video! Yep, why not? Man, we could make the "Subject:" field alone take up 125 MB if we just try hard enough! Besides, there are "thounsand" users wanting such feature. Sad, isn't it? > But to give you an example of when a lack is a highly to be desired > feature. > > Someone on the corner of the road I live in installed a very bright > security light that was triggered by a motion sensor. The result was > that as I approached the corner I was suddenly blinded by a very bright > light shining straight into my eyes. It was fairly soon removed, > presumably at the insistance of the Police. It was its _presence_ that > was the bug and its absence a highly desirable feature. I fail to see a direct relation between this example and Kmail html issue, because you cannot go and turn off the light (you are not allowed to do it so, but police) but you can still have plain text e-mail forwarding _or_ html e-mail forwarding: here the choice is fully yours. Sounds great. Except, the choice is fully yours. Which, given that, generally, 90% of the people will choose Windows over GNU/Linux, Word .doc format over open document standards, royalty-ridden multimedia formats over open ones, vendor lock-in over open hardware/drivers, or even super-sized hamburgers over healthy foods, can be a problem in itself. > So here. I regard the fact that my emails are blessedly HTML and > picture free as a strength, and a highly desirable feature. Having the option of using html e-mails does not mean you are forced to go that path, it is up to you when using plain text e-mail or html. Now, Kmail users do not have that choice. Unfortunately, many of us have that path quite simply *thrust upon us*. I wouldn't call that a choice by any stretch of the imagination. Ever tried updating your mail over a tethered UMTS phone because your DSL line just died or you're in the wild somewhere, with only your laptop and your GSM phone? It's an enlightening experience, at a flaky 2-3 kps. Particularly when you realize that the bulk of that 45-minutes download that has drained both your battery and your pre-paid GSM account, has been taken by a couple of unsolicited multimedia-infested HTML mails ... Give a man the Garden of Eden, and you may be pretty sure he'll eventually make a Middle-East Hell out of it. Oh, he
