On Thu, Feb 04, 2010 at 09:30:51PM +0100, Rado S wrote: > > As I said, I believe that if you need to have complexity, it > > should be in the code, not on the user end. > > The glue to accomplish complex goals needs not necessarily to be in > the user end, it can be put in meta-code (wrappers), which can be > constructed by advanced users to share with other user. See, this > already happens for mutt.
And this is exactly the problem. I'm not suggesting that Mutt should become outlook... I hate outlook. But when you have a requirement that things that are complex be done outside the app, it means: - It's not seamlessly integrated into the user's experience - Users need to engineer their own solutions - Invariably, many people re-engineer the same solution many times It's a monumental waste of effort. It's generally much, much better if someone takes the time to integrate the functionality into the program directly, so that users don't need to keep re-engineering it, or at least hunting down the solution that someone else engineered. > > Sure, Mutt has SMTP functionality now, but it took about a decade > > and a couple of changes of maintainers for that to happen. > > And I still don't consider it a good decision. :) That's only because YOU have no use for it. Lots of people do. The quality of Mutt has not suffered for having it... how can that not mean that Mutt is better for having it? > I favour the "user should know (the basics of) what he does/ uses" > argument over the user-convenience. People should know about their tools; that does not mean they should have to trade off convenience. Computers are tools; they're supposed to make our lives easier. You clearly appreciate learning for its own sake. The overwhelming majority of people who use computers don't feel that way about it. > The mass of unknowing users not wanting to care for how all the > stuff in the background works are free to join the OutLook/M$ crowd > by expanding "their" branch of mutt into OL. It's not that simple. Outlook sucks for a lot of reasons, many of them technical. Mutt has very few technical weaknesses, but its user interface is from 3 decades ago. I, and I suspect a lot of people, would love to see a modern Mutt. > > The advantage of a monolithic app is that, in cases where one is > > called for, most users usually won't care about those issues, and > > there's usually a lot less for them to worry about / manage with a > > monolithic app than with a bunch of smaller programs. > > Really? Yes, really. > You still have to give all the details required for (for example) > the MTA part; does it matter that you do it in the big-app on > another page or in a separate app? In both cases it is "elsewhere", > remote to the MUA part. It matters quite a lot. You ever try to configure sendmail from scratch? To configure Mutt's SMTP functionality, you need only know the answers to a handful of questions. To configure a full-fledged MTA, you may very well need to know a lot more than that. Some MTAs are easier than others... But what happens when it doesn't work? You probably have a long night ahead of you to figure out why. With Mutt's SMTP support, you tell it what smtp server to use, and if it doesn't work, you call your ISP and let them figure it out; the problem pretty much has to be on their end, if your settings are right... > The question is: do you follow the crowd (convenience) or make the > crowd follow you (learn how things work)? It has nothing to do with the crowd. It has everything to do with reducing the amount of work that I shouldn't need to do. That's the purpose of computers. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpMDstH6yAq4.pgp
Description: PGP signature
