On 8/19/01 8:57 PM, "J C Lawrence" <[EMAIL PROTECTED]> wrote:
> ObCaveat: I dissallow HTML on my lists both because I dislike it,
> and because of the security and privacy concerns it raises.
I do the same, but only because I haven't yet built a system that I feel
will pass styled text content with reasonable safety (you, by being attached
to the internet, can never create 100% safe systems, but as a list owner, I
feel a responsibility to mitigate the risks; after all, I'm the tech expert,
so I'm better qualified to do so than the users are. To put the onus on
users is a cop-out, IMHO). There will have to be tradeoffs here, but I think
on balance the benefits and user happiness outweigh the risks, once you
create the environment that deals with the problems it can/should deal with.
In the meantime, I've put the onus to "do the right thing" on the list
server, not on the end user. I don't believe in putting users through hoops
to use a system. I believe in putting the system through hoops to make it
work the way the user expects. Fortunatel, de-mime does what I need nicely,
and for this stuff, it "does the right thing" for me. So we end up with (for
now) plain text, but users don't have to fight their mailers to generate it.
This seems to be a reasonable compromise for now, and when users complain
about losing formatting, I simply say "viruses", and they usually
understand. But I think this is all a stopgap workaround, not a solution.
> For
> instance, I promise my list members anonymity both to the fact
> that they are on or off the list. Allowing HTML would sunder that
> promise (think web bugs).
And this is something JC and I have gone around on, and it all, I guess,
boils down to defining and documenting what "reasonable risk" is, and doing
what you can to educate users what risks still exist. He sets the bar a lot
higher than I do, but he knows his user base, so I won't pretend to judge
his decision -- we all have to know our audiences and do what's best for
them. There is no "audience" to design to, except in such broad generalities
it's almost worthless... After all, how do you reconcile the needs of my mom
on AOL with the people on this list? You can't: different populations
require different tradeoffs.
>> My point is that I think *WE'RE*WRONG* -- the view that the desire
>> to have nicely formatted email,
> This is a question of purpose, of what the purpose an intent of the
> list in question is.
Yup. And also, it's a question of comfort and history. Those of us who grew
up with ascii-only terminals and the like grew up with plain text. Wee know
it, we're comfortable with it, we don't feel the need to grow beyond it, and
we don't always see why others want stuff we don't feel are important.
Might as well sit down someone playing Quake 3 Arena and try to convince
them that rogue or hunt-the-wumpus are 'good enough'. You'd get the same
reaction, too.
That might be an interestiong question for the "text is good" group: have
you adopted new technologies elsehwere, or not? You still killing wumpus'?
(in all honesty, personally, I still stand firmly in both camps here; I
still love a good game of rogue or classic games like zork -- but I also
spend time with recent games, like Diablo II. But I felt wumpus was lame,
back when it was new....)
I'm sure most folks have happily adopted in some parts of the technology
that's come along; perhaps by realizing that, you'll be more sensitive to
others when they've decided to buy into things like styled text....
>> It is *WE* who are shovelling against the tide, trying to make
>> sure that it stays 1970 forever.
>
> Damned right.
And if you continue, you'll be like those old morse-code hacks in the ham
radio hobby; grumbling among an ever-shrinking group of guys about the good
old days, while the next generation of hams are off on the 2 meter repeater
having a fun chat.
I almost hate to harp on the ham radio stuff again, but I think it's a valid
comparison; if you talk to hams, you'll see there are some serious
(occasionally nasty, often political) generational schisms in the hobby.
Older hams most of the time were interested in building stuff as much as
using stuff. Younger hams were more interested in using -- and as the market
grew, more commercial gear became available, and a big schism developed
between the builders and buyers. There are still youngsters who enjoy
building radios and hacking on hardware, but they're a small minority now.
Similar schisms exist in woodworking (power vs. handtools, and
build-the-shop vs buy-the-shop, to name just two), astronomy (build/use
telescopes) -- name your interest, there there are groups fighting over what
the One True Way of doing things are.
Lots of it boils down to power games, pure and simple. But in almost all
cases, it's a losing fight -- because the other side will simply declare you
irrelevant and do what it wants, elsewhere.
Personally, I'd like to see us avoid these generational schisms on-line, and
liearn from them. Because when groups schism off and go do their own thing,
they have a bad tendency to reinvent mistakes we made and solved long ago,
because they're not listening.
That's why I argue for an adapt and adopt strategy, which involves
compromises on all sides. Adapt in this new stuff when it makes sense, and
adopt these new users and try to build a multi-generational community.
> I would have voted for [tn]roff or TeX, but that battle is long
> lost.
Jabber has defined where this is going: XML as the transport mechanism, and
clients on each side that translate to XML to send it, and from XML into
however your preferred viewing scheme is defined. Part of the transport XML
can define a preferred viewing definition for the method; the client has the
option of overwriting that -- to plain text, if it wants. And in the middle,
XML does what XML does best. Most data from one transformation to another.
--
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<[EMAIL PROTECTED]> = <[EMAIL PROTECTED]> = <[EMAIL PROTECTED]>]
Yes, yes, I've finally finished my home page. Lucky you.
The first rule of holes: If you are in one, stop digging.
