git.cworth.org Git - sup/blob - doc/Philosophy.txt

   1 Should an email client have a philosophy? For many people, email is
   2 one of our primary means of communication, and email archives are an
   3 integral part of our long-term memory. Something so important ought to
   4 warrant a little thought.
   5
   6 Here's Sup's philosophy.
   7
   8 Using "traditional" email clients today is increasingly problematic.
   9 Anyone who's on a high-traffic mailing list knows this. My ruby-talk
  10 folder is 430 megs and Mutt sits there for 60 seconds while it opens
  11 it. Keeping up with the all the new traffic is impossible, even with
  12 Mutt's excellent threading features, simply because there's so much of
  13 it. A single thread can span several pages in the folder index view
  14 alone! And Mutt is probably the fastest, most mailing-list aware email
  15 client out there. God help me if I try and use Thunderbird.
  16
  17 The problem with traditional clients like Mutt is that they deal with
  18 individual pieces of email. This places a high mental cost on the user
  19 for each incoming email, by forcing them to ask: Should I keep this
  20 email, or delete it? If I keep it, where should I file it? I've spent
  21 the last 10 years of my life laboriously hand-filing every email
  22 message I received and feeling a mild sense of panic every time an
  23 email was both "from Mom" and "about school". The massive amounts of
  24 email that many people receive, and the cheap cost of storage, have
  25 made these questions both more costly and less useful to answer.
  26
  27 Contrast that with using Gmail. As a long-time Mutt user, I was blown
  28 away when I first saw someone use Gmail. They treated their email
  29 differently from how I ever had. They never filed email and they never
  30 deleted it. They relied on an immediate, global, full-text search, and
  31 thread-level tagging, to do everything I'd ever done with Mutt, but
  32 with a trivial cost to the user at message receipt time.
  33
  34 From Gmail I learned that making certain operations quantitatively
  35 easier (namely, search) resulted in a qualitative improvement in
  36 usage. I also learned how thread-centrism was advantageous over
  37 message-centrism when message volume was high: most of the time, a
  38 message and its context deserve the same treatment. I think it's to
  39 the Gmail designers' credit that they started with a somewhat ad-hoc
  40 idea (hey, we're really good at search engines, so maybe we can build
  41 an email client on top of one) and managed to build something that was
  42 actually better than everything else out there. At least, that's how I
  43 imagine in happened. Maybe they knew what they were doing from the
  44 start.
  45
  46 Unfortunately, there's a lot to Gmail I can't tolerate (top posting,
  47 HTML mail, one-level threads, and ads come to mind, never mind the
  48 fact that it's not FOSS). Thus Sup was born.
  49
  50 Sup is based on the following principles, which I stole directly from
  51 Gmail:
  52
  53 - An immediately accessible and fast search capability over the entire
  54   email archive eliminates most of the need for folders, and most of
  55   the necessity of deleting email.
  56
  57 - Labels eliminate what little need for folders search doesn't cover.
  58
  59 - A thread-centric approach to the UI is much more in line with how
  60   people operate than dealing with individual messages is. In the vast
  61   majority of cases, a message and its context should be subject to
  62   the same treatment.
  63
  64 Sup is also based on many ideas from mutt and Emacs and vi, having to
  65 do with the fantastic productivity of a console- and keyboard-based
  66 application, the usefulness of multiple buffers, the necessity of
  67 handling multiple email accounts, etc. But those are just details!
  68
  69 Try it and let me know what you think.