In <pan.2010.10.31.21.36.24@gmail.com>, 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. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.