[sup-talk] Some comments on sup-0.6

* [sup-talk] Some comments on sup-0.6
@ 2008-08-23 23:15 Bart Schaefer
  2008-08-23 23:20 ` Luis Villa
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Bart Schaefer @ 2008-08-23 23:15 UTC (permalink / raw)

"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.

^ permalink raw reply	[flat|nested] 7+ messages in thread