* [sup-talk] On making kill-thread easier
@ 2009-08-20 17:07 Carl Worth
2009-08-20 18:19 ` Andrei Thorp
2009-08-20 20:01 ` Chris Wilson
0 siblings, 2 replies; 13+ messages in thread
From: Carl Worth @ 2009-08-20 17:07 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 17:07 [sup-talk] On making kill-thread easier Carl Worth
@ 2009-08-20 18:19 ` Andrei Thorp
2009-08-20 20:01 ` Chris Wilson
1 sibling, 0 replies; 13+ messages in thread
From: Andrei Thorp @ 2009-08-20 18:19 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 17:07 [sup-talk] On making kill-thread easier Carl Worth
2009-08-20 18:19 ` Andrei Thorp
@ 2009-08-20 20:01 ` Chris Wilson
2009-08-20 20:36 ` Andrei Thorp
2009-08-20 20:43 ` Ben Walton
1 sibling, 2 replies; 13+ messages in thread
From: Chris Wilson @ 2009-08-20 20:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 20:01 ` Chris Wilson
@ 2009-08-20 20:36 ` Andrei Thorp
2009-08-20 21:07 ` Carl Worth
2009-08-20 20:43 ` Ben Walton
1 sibling, 1 reply; 13+ messages in thread
From: Andrei Thorp @ 2009-08-20 20:36 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 20:01 ` Chris Wilson
2009-08-20 20:36 ` Andrei Thorp
@ 2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
` (2 more replies)
1 sibling, 3 replies; 13+ messages in thread
From: Ben Walton @ 2009-08-20 20:43 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread* [sup-talk] On making kill-thread easier
2009-08-20 20:43 ` Ben Walton
@ 2009-08-20 21:11 ` Carl Worth
2009-08-20 22:56 ` Ben Walton
2009-08-21 1:36 ` Carl Worth
2009-08-21 15:16 ` Chris Wilson
2 siblings, 1 reply; 13+ messages in thread
From: Carl Worth @ 2009-08-20 21:11 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 21:11 ` Carl Worth
@ 2009-08-20 22:56 ` Ben Walton
2009-08-21 0:09 ` Carl Worth
0 siblings, 1 reply; 13+ messages in thread
From: Ben Walton @ 2009-08-20 22:56 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 22:56 ` Ben Walton
@ 2009-08-21 0:09 ` Carl Worth
0 siblings, 0 replies; 13+ messages in thread
From: Carl Worth @ 2009-08-21 0:09 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
@ 2009-08-21 1:36 ` Carl Worth
2009-08-21 15:16 ` Chris Wilson
2 siblings, 0 replies; 13+ messages in thread
From: Carl Worth @ 2009-08-21 1:36 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
2009-08-21 1:36 ` Carl Worth
@ 2009-08-21 15:16 ` Chris Wilson
2009-08-21 15:19 ` Edward Z. Yang
2009-08-21 15:20 ` Ben Walton
2 siblings, 2 replies; 13+ messages in thread
From: Chris Wilson @ 2009-08-21 15:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-21 15:16 ` Chris Wilson
@ 2009-08-21 15:19 ` Edward Z. Yang
2009-08-21 15:20 ` Ben Walton
1 sibling, 0 replies; 13+ messages in thread
From: Edward Z. Yang @ 2009-08-21 15:19 UTC (permalink / raw)
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?
> -ickle
A -> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [sup-talk] On making kill-thread easier
2009-08-21 15:16 ` Chris Wilson
2009-08-21 15:19 ` Edward Z. Yang
@ 2009-08-21 15:20 ` Ben Walton
1 sibling, 0 replies; 13+ messages in thread
From: Ben Walton @ 2009-08-21 15:20 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-08-21 15:20 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-20 17:07 [sup-talk] On making kill-thread easier Carl Worth
2009-08-20 18:19 ` Andrei Thorp
2009-08-20 20:01 ` Chris Wilson
2009-08-20 20:36 ` Andrei Thorp
2009-08-20 21:07 ` Carl Worth
2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
2009-08-20 22:56 ` Ben Walton
2009-08-21 0:09 ` Carl Worth
2009-08-21 1:36 ` Carl Worth
2009-08-21 15:16 ` Chris Wilson
2009-08-21 15:19 ` Edward Z. Yang
2009-08-21 15:20 ` Ben Walton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox