[sup-talk] Some comments on sup-0.6

From: luis@tieguy.org (Luis Villa)
Subject: [sup-talk] Some comments on sup-0.6
Date: Sat, 23 Aug 2008 19:20:22 -0400	[thread overview]
Message-ID: <2cb10c440808231620k57396f1bw8547db09dded6abf@mail.gmail.com> (raw)
In-Reply-To: <6bb609560808231615o1b7dc71eh48d192375e46cf8c@mail.gmail.com>

Possibly of interest, Bart:
http://all-thing.net/2008/06/rethinking-sup.html
http://all-thing.net/2008/07/rethinking-sup-part-ii.html

Luis (who isn't actually using sup, for many of the reasons you
listed, but remains a fascinated lurker)

On Sat, Aug 23, 2008 at 7:15 PM, Bart Schaefer
<barton.schaefer at gmail.com> wrote:
> "The goal of Sup is to become the email client of choice for nerds everywhere."
>
> I encountered sup a few days ago via a link on Justin Mason's blog,
> and it sounded interesting enough to try it out.  There are quite a
> few things about it that I like, but there are a few things about it
> that currently are just plain show-stoppers.  None of them is
> irreparable, but IMO taken together they almost disqualify it from
> being called an "email client" at this time.
>
> First the good stuff:  I entirely approve of the choices of ideas to
> borrow from gmail, and the addition of being able to mark and coalesce
> threads is something I wish gmail would borrow back.  The key bindings
> weren't too hard to figure out (and probably would have been easier if
> I'd used mutt more in the past).  The expanding/collapsing views of
> threads and quoted messages work nicely most of the time.  I could
> immediately see how sup could help me clean up the mess some of my
> mail stores have become, to find and conceal old stuff without
> completely losing track of it and prioritize important stuff.  Great
> work.
>
> (At the same time, that last is what seems to be lacking in
> follow-through.  See below.)
>
> One suggestion for an improvement on the gmail interface:  Consider
> introducing a hierarchy syntax in labels.   E.g., if I've got a label
> for "restaurants" I might create a label "restaurants/lunch" that
> means "first search for anything tagged restaraurants and then narrow
> by searching for anything also tagged lunch".  In any UI that shows a
> list of the labels, collapse the heirarchy so that I don't have to see
> both "restaurants" and "restaurants/lunch" at the same time.  This
> creates an interface familiar to users who are accustomed to having
> folders arranged hierarchically, without changing the search model
> that ultimately locates the referenced messages.
>
> (Is it possible to search for messages based on which source they came from?)
>
> Next some nits or minor problems, in no particular order ...
>
> The default color scheme is pretty terrible.  (I did mention there'd be "nits".)
>
> When I widened my terminal window to try to see more of the preview
> text on the thread screen, sup didn't pick up on the size change.
>
> There's either no on-screen help for how one builds up a search
> expression, or it's simply too hard to find that help, and in
> particular it wasn't obvious how one searches for all messages having
> a certain label (I was expecting maybe something like gmail's
> label:Xyz syntax).
>
> It should be possible to create search that matches a label without
> finding other messages that happen to contain the same word (maybe it
> is possible and I just haven't figure out how yet).
>
> I happened to encounter a case of new mail arriving while I was using
> sup, wherein a colleague had replied to a message by editing the
> Subject such that his entire reply was there and the message body was
> empty.  Sup collapsed this into the thread and hid his new subject
> behind the original subject.  I had to bail out and switch over to
> alpine to figure out why he'd sent a seemingly empty message.
>
> OK, now the show stoppers.
>
> I have a LOT of IMAP folders (conservatively, hundreds), many of them
> in a shared hierarchy not under my control; sup's interface would be
> the perfect way to get a handle on these, but it would take me way too
> long to add them one by one as separate URL sources.  At the moment
> sup might be described as phenomenal cosmic power in an itty-bitty
> living space.
>
> If you're going to have any hope of becoming the choice of nerds
> everywhere, you've got address the "play well with others" problem, at
> the very least with the IMAP INBOX, if not with other mailboxes.
> Forcing me to exit from sup and do a complete re-index whenever a
> message disappears is just not going to fly, particularly for a
> protocol that provides so many tools for keeping in sync.  I know,
> this doesn't fit with the "never delete anything, just stop looking at
> it" model that sup wants to present, but in the real world even nerds
> can't store things in their inbox forever, and for it to really be THE
> email client of choice, I want to keep sup running for weeks at a time
> and never have a reason to leave the interface (except maybe to escape
> to a web browser or to drop into my editor when composing mail).
>
> By the same token, sup needs to be able to push deletion marks back up
> to the IMAP server and purge the mailbox.  Even if you violate the
> IMAP usage model by implementing delete as some kind of move-to-trash
> operation, so that sup can keep indexing the trash, there has to be a
> way for the user to manage the size of his inbox without switching to
> some other means of accessing the server.  And to really take
> advantage of sup's ability to search and classify to clean up my messy
> mail store, I need a way to permanently throw away all the spam and
> duplicate messages that have accumulated in the odd procmail-created
> corners of my folder space.  It's even fine if the only way to do this
> is through IMAP or the like; sup does not need to incorporate the
> mechanics of local mailbox management.
>
> That's about it for impressions from a few hours of experimentation.
> I think sup shows great promise and I've joined the mailing list to
> keep track of its progress.  Congratulations on what you've got so
> far, and I look forward to seeing more.
> _______________________________________________
> sup-talk mailing list
> sup-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>