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

   1 Should an email client have a philosophy? I think so. For many people,
   2 email is our primary means of communication. Something so important
   3 ought to warrant a little thought.
   4
   5 So here's Sup's philosophy.
   6
   7 Using "traditional" email clients today is increasingly problematic.
   8 Anyone who's on a high-traffic mailing list knows this.  My ruby-talk
   9 folder is 350 megs and Mutt sits there for 60 seconds while it opens
  10 it. Keeping up with the all the new traffic is painful, even with
  11 Mutt's excellent threading features, simply because there's so much of
  12 it---a single thread can span several pages, and God help you if you
  13 lag behind. And Mutt is probably the best email client out there in
  14 terms of threading and mailing list support. God help me if I try and
  15 throw Thunderbird at that.
  16
  17 The principle problem with traditional clients is that they deal with
  18 individual pieces of email, and place 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?
  21
  22 I've spent the last 10 years of my life laboriously hand-filing every
  23 email message I received and feeling a mild sense of panic every time
  24 an email was both "from Mom" and "about school". The massive amounts
  25 of email that many people receive, and the cheap cost of storage, have
  26 made these questions both more costly and less useful to answer.
  27
  28 As a long-time Mutt user, when I first watched people use GMail, I saw
  29 them use email differently from how I had ever used it. I saw that
  30 making certain operations quantitatively easier (namely, search)
  31 resulted in a qualitative difference in usage: you don't have to worry
  32 about filing correctly, because you can always find things later by
  33 search. And I saw that thread-centrism had many advantages over
  34 message-centrism when message volume was high.
  35
  36 So, in many ways, I believe GMail has taken the right approach to
  37 handle both of the factors above, and much of the inspiration for Sup
  38 was based on GMail. I think it's to the GMail designers' credit that
  39 they started with a somewhat ad-hoc idea (hey, we're really good at
  40 search engines, so can we build an email client on top of one?) and
  41 managed to build something that was actually better than everything
  42 else out there. But ultimately, GMail wasn't right for me (see FAQ),
  43 which is why the idea for Sup was born.
  44
  45 Sup is based on the following principles, which I more or less stole
  46 directly from GMail:
  47
  48 - An immediately accessible and fast search capability over the
  49   entire email archive eliminates most of the need for folders,
  50   and eliminates the necessity of having to ever delete email.
  51
  52 - Labels eliminate what little need for folders that search doesn't
  53   eliminate.
  54
  55 - A thread-centric approach to the UI is much more in line with how
  56   people operate than dealing with individual messages is. In the vast
  57   majority of cases, a message and its context should be subject to
  58   the same treatment.
  59
  60 Sup is also based on many ideas from mutt and Emacs and vi, having to
  61 do with the fantastic productivity of a console- and keyboard-based
  62 application, the usefulness of multiple buffers, the necessity of
  63 handling multiple email accounts, etc.
  64
  65 Give it a go and let me know what you think.