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 <[EMAIL PROTECTED]> 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
