I wrote a long post that started out talking about workflows, but then went on into just a dump of feature requests. I''d like to get back to talking about workflows again a bit. I find that when processing my mail in inbox-mode I do a first pass with one of two different actions on each thread: 1. ''a'' to archive the thread without reading or: 2. <down-arrow> to leave the thread in my inbox for reading on a later pass. But this misses out on the killer-feature that was one of the things that made me most interested in sup: kill-thread. So I can currently decide to kill a thread instead of archiving it, but this requires extra effort on my part, (deciding that I need to do something more than just archiving it, and then using a different key---currently with a keybinding that requires two keys). What I find is that I end up using kill-thread much less frequently than I should. Basically what ends up happening is that when a thread comes up several times (and I keep just archiving it) before I finally make the mental effort to kill it instead of just archiving it. And I keep trying to train myself to not be afraid to use kill-thread more frequently. But then thought occurs to me, "Shouldn''t sup just see that I''m not ever reading this thread when it reappears?". So I think what I actually want is a single keybinding that either archives or kills a thread based on whether I''ve actually read any of it or not. Does anybody else agree that that would be useful? Perhaps even as the default? I think a first pass that only does kill-thread if the entire thread is unread will likely be enough. I can imagine a more clever version that kills a thread even if it''s partially read but no new messages have been read since the last time this thread was labelled as inbox. But that''s perhaps more complexity than appropriate[*] and an explicit kill-thread command will work just fine here. -Carl [*] By the way, my concern with complexity has nothing to do with the state management in the code---that shouldn''t be bad. It''s more a matter of making the user-interface easy to explain and understand. If a tool violates that, then it can lose a user''s trust, (which can be quite fatal for a mail client). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/aefd9813/attachment.bin>
Excerpts from Carl Worth''s message of Thu Aug 20 13:07:16 -0400 2009:> I wrote a long post that started out talking about workflows, but then > went on into just a dump of feature requests. I''d like to get back to > talking about workflows again a bit. > > I find that when processing my mail in inbox-mode I do a first pass > with one of two different actions on each thread: > > 1. ''a'' to archive the thread without reading > or: > 2. <down-arrow> to leave the thread in my inbox for reading on > a later pass. > > But this misses out on the killer-feature that was one of the things > that made me most interested in sup: kill-thread. > > So I can currently decide to kill a thread instead of archiving it, > but this requires extra effort on my part, (deciding that I need to do > something more than just archiving it, and then using a different > key---currently with a keybinding that requires two keys). > > What I find is that I end up using kill-thread much less frequently > than I should. Basically what ends up happening is that when a thread > comes up several times (and I keep just archiving it) before I finally > make the mental effort to kill it instead of just archiving it. And I > keep trying to train myself to not be afraid to use kill-thread more > frequently. > > But then thought occurs to me, "Shouldn''t sup just see that I''m not > ever reading this thread when it reappears?". > > So I think what I actually want is a single keybinding that either > archives or kills a thread based on whether I''ve actually read any of > it or not. Does anybody else agree that that would be useful? Perhaps > even as the default? > > I think a first pass that only does kill-thread if the entire thread > is unread will likely be enough. I can imagine a more clever version > that kills a thread even if it''s partially read but no new messages > have been read since the last time this thread was labelled as > inbox. But that''s perhaps more complexity than appropriate[*] and an > explicit kill-thread command will work just fine here. > > -Carl > > [*] By the way, my concern with complexity has nothing to do with the > state management in the code---that shouldn''t be bad. It''s more a > matter of making the user-interface easy to explain and understand. If > a tool violates that, then it can lose a user''s trust, (which can be > quite fatal for a mail client).Seems like making it the default is a bit cavalier. It''s not good to assume what the user wants, I think. Maybe a separate key if we want to spare it, but I think the better solution is "learn to kill threads already and use an explicit command for it." -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Hi everybody! I''ve just started using sup after Carl told me he''d found a fantastic new mail client. And, as usual, he was right. Excerpts from Carl Worth''s message of Thu Aug 20 18:07:16 +0100 2009:> But then thought occurs to me, "Shouldn''t sup just see that I''m not > ever reading this thread when it reappears?".I have a very similar inbox pattern to Carl, a quick pass to remove uninteresting material before acting upon the rest. To this end, I use ''&'' far less frequently than I should, because it''s an awkward key combination to use in conjunction with scrolling + archiving, and so I am irritated by repeatedly archiving a thread which I have never read. The behaviour I would like here is exactly: "Shouldn''t sup just see that I''m not ever reading this thread when it reappears?". I''d be happy to have sup automatically kill a thread that I have archived twice without reading. -ickle
Excerpts from Chris Wilson''s message of Thu Aug 20 16:01:10 -0400 2009:> Hi everybody! I''ve just started using sup after Carl told me he''d found > a fantastic new mail client. And, as usual, he was right.If you''re half as verbose as he is, I''ll never have time to read it all! ;) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
Excerpts from Chris Wilson''s message of Thu Aug 20 16:01:10 -0400 2009:> I have a very similar inbox pattern to Carl, a quick pass to remove > uninteresting material before acting upon the rest. To this end, I use > ''&'' far less frequently than I should, because it''s an awkward key > combination to use in conjunction with scrolling + archiving, and so I > am irritated by repeatedly archiving a thread which I have never read. > The behaviour I would like here is exactly: "Shouldn''t sup just see that > I''m not ever reading this thread when it reappears?".I have a similar pattern where there are lots of list messages that I don''t care about (based on subject). I skim the inbox using ''t'' to tag all messages I don''t care about. When I''ve tagged a bunch of items, after the scan, I simply to ''='' followed by either ''A'' (archive, mark read) or ''&''. It saves lots of shift key use and allows me to quickly tackle a lot of mail.> I''d be happy to have sup automatically kill a thread that I have > archived twice without reading.I think this kind of heuristic is a) hard to get right b) not required if you do batch operations as described above. Part b) is subject to personal opinion, of course! :) HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/1dbd06f5/attachment.bin>
Excerpts from Andrei Thorp''s message of Thu Aug 20 13:36:15 -0700 2009:> Excerpts from Chris Wilson''s message of Thu Aug 20 16:01:10 -0400 2009: > > Hi everybody! I''ve just started using sup after Carl told me he''d found > > a fantastic new mail client. And, as usual, he was right. > > If you''re half as verbose as he is, I''ll never have time to read it all! > ;)Yeah, sorry about that. I will try to be terse when I can. :-) Welcome, Chris! -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/481671be/attachment.bin>
Excerpts from Ben Walton''s message of Thu Aug 20 13:43:08 -0700 2009:> Excerpts from Chris Wilson''s message of Thu Aug 20 16:01:10 -0400 2009: > I have a similar pattern where there are lots of list messages that I > don''t care about (based on subject). I skim the inbox using ''t'' to > tag all messages I don''t care about. When I''ve tagged a bunch of > items, after the scan, I simply to ''='' followed by either ''A'' > (archive, mark read) or ''&''. It saves lots of shift key use and > allows me to quickly tackle a lot of mail.Thanks, Ben! This is just the kind of workflow report I''ve been hoping to read. I wonder, though, what happens when you want to archive some and kill others. Do you end up making two passes? Executing the ''='' operation partway through and then start tagging again? A quick, non-tag ''A'' or ''&'' for the exceptional thread? Or maybe just let a few slip by the "wrong" direction.> > I''d be happy to have sup automatically kill a thread that I have > > archived twice without reading. > > I think this kind of heuristic is a) hard to get right b) not required > if you do batch operations as described above. Part b) is subject to > personal opinion, of course! :)I plan to try a single keybinding for archive-or-kill-if-unread for a while and see how I like it, (I''ll obviously share it when I code it up).. Of course, the failure mode is hiding messages from me, so it might be hard for me to know if it fails. :-) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/cec04ef5/attachment.bin>
Excerpts from Carl Worth''s message of Thu Aug 20 17:11:49 -0400 2009:> I wonder, though, what happens when you want to archive some and kill > others. Do you end up making two passes? Executing the ''='' operation > partway through and then start tagging again? A quick, non-tag ''A'' or > ''&'' for the exceptional thread? Or maybe just let a few slip by the > "wrong" direction.I typically do a big pass to ''A'' or ''&'' large numbers of things. That knocks the list to a point where I can either do another smaller pass where I''ll apply labels and skim things. My last pass is for things I actually read, many of which get archived right away too. I don''t completely practice ''inbox 0'' but I do follow many of its tenets. My own personal habits are such that an archived thread has to really bug me before I kill it, so much of the first (morning) pass is for ''A.'' Part of this is because while I don''t want to necessarily follow a thread, there is potential for interesting things to pop in late in the game (many of these are on the git ml)...so, after I see a lot of activity on it, I may scan the thread or possibly read it. Bike shedding gets killed quickly! :)> I plan to try a single keybinding for archive-or-kill-if-unread for a > while and see how I like it, (I''ll obviously share it when I code it > up).. Of course, the failure mode is hiding messages from me, so it > might be hard for me to know if it fails. :-)If you get into adding code, consider writing it such that there is an available Hook that overrides the default behaviour. This may get you the best of all outcomes. It''d be useful for you and more likely to be useful for others. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/0226132d/attachment.bin>
Excerpts from Ben Walton''s message of Thu Aug 20 15:56:52 -0700 2009:> My own personal habits are such that an archived thread has to really > bug me before I kill it, so much of the first (morning) pass is for > ''A.'' Part of this is because while I don''t want to necessarily follow > a thread, there is potential for interesting things to pop in late in > the game (many of these are on the git ml)...so, after I see a lot of > activity on it, I may scan the thread or possibly read it.Thanks. Those are good points. I''ve definitely seen some interesting stuff on the git mailing list where threads start off looking worthless, but then Linus comes in with some gem of insight and things take off again. See Joey''s post on thread patterns for some examples here: http://joey.kitenet.net/blog/entry/thread_patterns/> Bike shedding gets killed quickly! :)Yes! Bike shedding without kill-thread available is a lot more painful. I guess part of what I''m getting at with the idea of merging "archive" and "kill-thread" is that I think the distinction between these two commands forces the user to get a little too chummy with details of the mail store. I wrote a long post about sup and mail in general here: http://cworth.org/sup/a-mail-client-for-geeks/ [*] and one of the ideas I start talking about there is that I''d like my mail client to present me with "Here''s what you should find most interesting right now", and I can implicitly give the system feedback by either reading it or not. So "archive" vs. "kill" feels like manual tuning of what would ideally be an automated process. Of course, getting that process automated and working well is likely an open research topic. I''d love for the system to take tags into account, authors of messages, my history of reading (or not) posts by given authors, etc. Obviously, sup''s not going to acquire that kind of functionality instantly, but it likely makes a good basis already for someone who wants to explore that kind of thing. So, ideas of mine like "sort certain tags before sorting by date", and "merge archive and thread into a single key" I think are both just baby steps toward the Big Idea I''d love to see someone tackle. Anyone looking for a good M.S. thesis around here? (So much research has been dedicated to spam, but has there been as much to sorting out the ham? I should ask my C.S-professor-friend---he''d be up on the current state of the literature here.) -Carl [*] See, I''m keeping some of my verbosity off the list at least. ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/3ed0cc42/attachment.bin>
Excerpts from Ben Walton''s message of Thu Aug 20 13:43:08 -0700 2009:> Excerpts from Chris Wilson''s message of Thu Aug 20 16:01:10 -0400 2009: > > > I''d be happy to have sup automatically kill a thread that I have > > archived twice without reading. > > I think this kind of heuristic is a) hard to get right b) not required > if you do batch operations as described above. Part b) is subject to > personal opinion, of course! :)[Here''s one last thought from me in this thread before I come back next time with actual code and maybe some experience in using it.] Since, by nature of being a heuristic, this kind of thing can''t be perfect, and since the cost of a false positive is high, (an important message being killed and never seen), here''s another idea: First, leave killing to the user as an explicit action. Second, use the heuristics not for killing messages, but merely for prioritizing them in the inbox. But since the inbox might often be small, it''s not adequate to move the "uninteresting" messages to the bottom. Instead threads that the heuristic identifies as "likely uninteresting" could have a delay attached to them before they are presented again in the inbox, (not too unlike throttling proposed for mailing-list servers to keep flamewars in check). This way instead of pestering the user with the bikeshedding until the user finally kills the thread in frustration, the bikeshedding could get delayed until the next morning''s sweep where a day''s worth of bikeshedding would be easy to identify and easy to kill. So maybe something like "Once I archive a thread twice without reading, don''t show it to me again until tomorrow" or so. That might be interesting to try out. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/aefb8350/attachment.bin>
Excerpts from Ben Walton''s message of Thu Aug 20 21:43:08 +0100 2009:> I skim the inbox using ''t'' to > tag all messages I don''t care about. When I''ve tagged a bunch of > items, after the scan, I simply to ''='' followed by either ''A'' > (archive, mark read) or ''&''.This works very nicely, thanks. Though I miss the subtly of why you use ''A'' rather than ''a''. Could you explain the difference this makes? -ickle
Excerpts from Chris Wilson''s message of Fri Aug 21 11:16:26 -0400 2009:> This works very nicely, thanks. Though I miss the subtly of why you > use ''A'' rather than ''a''. Could you explain the difference this makes? > -ickleA -> mark as read and archive a -> just archive This means you can have unread messages that are archived. I use this to great effect with my mailing list messages (which I have filters to archive but not to mark read). Cheers, Edward
Excerpts from Chris Wilson''s message of Fri Aug 21 11:16:26 -0400 2009:> This works very nicely, thanks. Though I miss the subtly of why you > use ''A'' rather than ''a''. Could you explain the difference this makes?''A'' marks the mail as read in addition to archiving it. This makes ''U'' (unread view) mode better for my use. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090821/9b947b49/attachment.bin>