<<< Date Index >>>     <<< Thread Index >>>

Re: reading color quoted replies



On Thu, Feb 01, 2007 at 07:21:07PM +0100, Rado S wrote:
> =- David Champion wrote on Thu  1.Feb'07 at 10:25:13 -0600 -=
> 
> > > i.e. the way of aiding is not stored in the data
> > > itself but left up to the reader (the original www idea).
> > >  A tool can perform its beefing-up well enough on this simple/
> > > raw data, too, as mutt and other MUAs show.
> > 
> > I agree with you, and I prefer that too, and from his post I
> > think Marc is in our camp.
> 
> However, Marc is uncertain about bringing this up with his
> limited-/ outlook-only-/ awareness collegues.
> 

I just don't understand how it's practical, or is necessarily a good
thing for mutt/mutters to go on that sort of pilgrimage. 

> > But most people don't care that much, as long as they can tell
> > the difference in their way, and most people don't want to
> > deviate too far from whatever happens by default.
> 
> That's true ... but is this (default=outlook/ html exclusive) what
> we mutters want? (Marc being the one in this case)
> This reasoning prevents freedom of "weapon"-choice/ personal
> optimization/ general improvement: that's what mutters want.
> 
> Not all defaults/ features are good just because they came first.
> Isn't every company/ undertaking interested in improvement to
> better succeed? Better "interoperability" suits them, too!
> (Especially when they learn that there's an eMail-world beyond
> the company limits. ;)

This just isn't realistic.  What sort of view of mutt do you think an
outlook user (potential mutt user) is going to get if I tell them "Hey
check out this great text based MUA that I have... only thing is,  you
know that feature that everyone in the office loves to use with their
clients, well you have to tell them not to use it."  The reality is that
they're going to be thinking "Why would anyone be using a client that
crippled them in that way?"  And if that's what they're thinking then
they're not going to have the view of "interoperability" that you
suggest, they're going to view mutt as a program that doesn't (fully)
support an "interoperable" standard like html.

Shouldn't the mutt developer take your point of view and be interested
in improvement to better succeed?  In reality, it's mutt's success in
retaining and building a user base that's more in jeopardy than my
company loosing potential business with mutters.

> 
> As often as people don't care for "a better" way, as often they
> don't care for _any_ way, as long as it doesn't bother them much.
> They just need a clue not to worry about a minor easy change (like
> selecting text/plain '> ' quoting over html in an options box) and
> some "conviction" to actually make the step.
> People are more friendly/ helpful than many of us worry they are not.

Even if they are friendly and comply, ultimately it works against you
(see above).

> Why keep "suffering" if things can be _easily_ changed when known?
> When people learn that a _simple_ change helps both sides without
> permanent losses to anyone, they are likely to apply it.
> If _we_ mutters don't do anything about it, it won't change by
> itself, as you noted _they_ won't do on their own.
> 
> So... what's there to lose? Temporary friction.
> What is to gain? Lasting improvement for all.
> What does it take: just to ask them and patience to work against
> an inert mass.
> It won't hurt Marc to ask, except he's afraid of asking.
> 

I'm not afraid to ask, I'm just wise enough to know that its futile, or
worse, detrimental.

> > Trying to persuade them otherwise often just makes one seem... well,
> > too interested in telling others how to work, to put it gently.
> > Although I'd love for everyone to work my way, telling them that
> > they should usually doesn't work out very well.
> 
> The problem is that mere trying/ learning/ asking is considered as
> negative force that must be denied, as if thinking hurts them,
> even more so any actual effort no matter how small and despite no
> permanent drawbacks for them once applied.
> 
> So it's better not even to try to make things better?
> You (Marc) want to support this ignorance?
> It's up to you, you have to live with either consequence (short
> term no pain or long term gain), neither David nor I. ;)
> 
> Improvement doesn't come without change, and this always causes
> friction to some end: no gain without pain. It's just a matter whether
> you want a) improvement and b) are willing to do what it takes.
> 
> Often enough it only takes just a little to gain a lot.
> The sad thing is people are too scared to make even smallest steps
> and see the big gain that lies behind it.

Yes, but equally sad are those who waste their lives pipe dreaming.
Having enough foresight to know which battles will bring gain sorts the
successful from the unsuccessful.

Marc