X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=doc%2FPhilosophy.txt;h=bdbe28f4198617c22809a522ff84fa270afc59b6;hb=1f2933ab23c6bb1acd21bce07b60d8f79c9eb999;hp=98ba8d1a84cabb748bd1f582aa13a02be466845e;hpb=00f2926f719103f60536234a2897d51c8a06bb2d;p=sup diff --git a/doc/Philosophy.txt b/doc/Philosophy.txt index 98ba8d1..bdbe28f 100644 --- a/doc/Philosophy.txt +++ b/doc/Philosophy.txt @@ -1,56 +1,60 @@ -Should an email client have a philosophy? I think so. For many people, -email is one of our primary means of communication. Something so -important ought to warrant a little thought. +Should an email client have a philosophy? For many people, email is +one of our primary means of communication, and email archives are an +integral part of our long-term memory. Something so important ought to +warrant a little thought. -So here's Sup's philosophy. +Here's Sup's philosophy. Using "traditional" email clients today is increasingly problematic. -Anyone who's on a high-traffic mailing list knows this. My ruby-talk -folder is 350 megs and Mutt sits there for 60 seconds while it opens -it. Keeping up with the all the new traffic is painful, even with +Anyone who's on a high-traffic mailing list knows this. My ruby-talk +folder is 430 megs and Mutt sits there for 60 seconds while it opens +it. Keeping up with the all the new traffic is impossible, even with Mutt's excellent threading features, simply because there's so much of it. A single thread can span several pages in the folder index view -alone! And Mutt is probably the fastest email client out there in -terms of threading and mailing list support. God help me if I try and -throw Thunderbird at that. +alone! And Mutt is probably the fastest, most mailing-list aware email +client out there. God help me if I try and use Thunderbird. -The principle problem with traditional clients is that they deal with +The problem with traditional clients like Mutt is that they deal with individual pieces of email. This places a high mental cost on the user for each incoming email, by forcing them to ask: Should I keep this -email, or delete it? If I keep it, where should I file it? -For example, I've spent the last 10 years of my life laboriously -hand-filing every email message I received and feeling a mild sense of -panic every time an email was both "from Mom" and "about school". The -massive amounts of email that many people receive, and the cheap cost -of storage, have made these questions both more costly and less useful -to answer. +email, or delete it? If I keep it, where should I file it? I've spent +the last 10 years of my life laboriously hand-filing every email +message I received and feeling a mild sense of panic every time an +email was both "from Mom" and "about school". The massive amounts of +email that many people receive, and the cheap cost of storage, have +made these questions both more costly and less useful to answer. -As a long-time Mutt user, when I first watched people use GMail, I saw -them use their email client differently from how I had ever used it. I -saw that making certain operations quantitatively easier (namely, -search) resulted in a qualitative difference in usage: you don't have -to worry about filing correctly, because you can always find things -later by search. And I saw that thread-centrism had many advantages -over message-centrism when message volume was high. +Contrast that with using Gmail. As a long-time Mutt user, I was blown +away when I first saw someone use Gmail. They treated their email +differently from how I ever had. They never filed email and they never +deleted it. They relied on an immediate, global, full-text search, and +thread-level tagging, to do everything I'd ever done with Mutt, but +with a trivial cost to the user at message receipt time. -So, in many ways, I believe GMail has taken the right approach to -handle both of the factors above, and much of the inspiration for Sup -was based on GMail. I think it's to the GMail designers' credit that -they started with a somewhat ad-hoc idea (hey, we're really good at -search engines, so maybe we can build an email client on top of one) -and managed to build something that was actually better than -everything else out there. But ultimately, GMail wasn't right for me -(see FAQ), which is why the idea for Sup was born. +From Gmail I learned that making certain operations quantitatively +easier (namely, search) resulted in a qualitative improvement in +usage. I also learned how thread-centrism was advantageous over +message-centrism when message volume was high: most of the time, a +message and its context deserve the same treatment. I think it's to +the Gmail designers' credit that they started with a somewhat ad-hoc +idea (hey, we're really good at search engines, so maybe we can build +an email client on top of one) and managed to build something that was +actually better than everything else out there. At least, that's how I +imagine in happened. Maybe they knew what they were doing from the +start. -Sup is based on the following principles, which I more or less stole -directly from GMail: +Unfortunately, there's a lot to Gmail I can't tolerate (top posting, +HTML mail, one-level threads, and ads come to mind, never mind the +fact that it's not FOSS). Thus Sup was born. -- An immediately accessible and fast search capability over the - entire email archive eliminates most of the need for folders, - and eliminates the necessity of having to ever delete email. +Sup is based on the following principles, which I stole directly from +Gmail: -- Labels eliminate what little need for folders that search doesn't - eliminate. +- An immediately accessible and fast search capability over the entire + email archive eliminates most of the need for folders, and most of + the necessity of deleting email. + +- Labels eliminate what little need for folders search doesn't cover. - A thread-centric approach to the UI is much more in line with how people operate than dealing with individual messages is. In the vast @@ -62,4 +66,4 @@ do with the fantastic productivity of a console- and keyboard-based application, the usefulness of multiple buffers, the necessity of handling multiple email accounts, etc. But those are just details! -Give it a go and let me know what you think. +Try it and let me know what you think.