-Should an email client have a philosophy? I think so. For many people,
-email is 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, and God help you if you
-lag behind. And Mutt is probably the best email client out there in
-terms of threading and mailing list support.
-
-The principle problem with traditional clients is that they place 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.
-
-As a long-time Mutt user, when I watched people use GMail, I saw them
-use email 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. And I saw that thread-centrism had
-many advantages over message-centrism, especially when volume was high.
-
-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. Ultimately, GMail wasn't right for me, which is
-why the idea for Sup was born.
-
-Sup is based on the following principles, which I more or less stole
-directly from GMail:
-
-- 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.
-
-- Labels eliminate the remaining need for folders.
+it. A single thread can span several pages in the folder index view
+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 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? 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.
+
+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.
+
+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.
+
+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.
+
+Sup is based on the following principles, which I stole directly from
+Gmail:
+
+- 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. A message
- and its content deserve the same treatment in the vast majority
- of cases.
+ people operate than dealing with individual messages is. In the vast
+ majority of cases, a message and its context should be subject to
+ the same treatment.
Sup is also based on many ideas from mutt and Emacs and vi, having to
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.
+handling multiple email accounts, etc. But those are just details!
+Try it and let me know what you think.
projects / sup / blobdiff