Preventing the user shooting themself in the foot

[Carl Worth]

On Thu, 30 Jun 2011 13:04:23 +1000, Brian May <brian at microcomaustralia.com.au> wrote:
> On 30 June 2011 08:40, Carl Worth <cworth at cworth.org> wrote:
> > The 'a' keybinding, (in turn), was designed for cases when you *know*
> > you don't want to read the rest of the thread.
> 
> ... in which case it should also mark everything as read. IMHO.

I know the current behavior only catches my opinion (and only an opinion
I had at one particular point in time). So I won't say this is Right,
but I will at least explain what I was thinking:

The "unread" tag is distinct from the "inbox" tag. Why two tags? Don't
they normally change at the same time? If a key like 'a' got rid of the
"unread" tag as well as the "inbox" then there would be almost no need
for having two tags.

The idea I had is that "inbox" is fully under explicit control by the
user. The user must make an intentional decision to "archive" a message
in order for that tag to be removed.

Distinct from that is "unread" which is handled automatically by the
mail client (as well as it can tell what you've actually read or
not). So this tag is removed only implicitly, (we don't have specific
commands to manipulate the "unread" tag). When the client displays a
message as the "current" message it immediately removes the "unread"
tag.

 Whenever it displays a message to the
user, (as the "current" message), it removes the unread tag from that
message.

This means that messages can lose the "unread" tag while still remaining
tagged "inbox", (you read a message, but don't archive it), and that
messages can lose the "archive" tag while still remaining tagged
"unread", (you archive a thread before reading all messages in the
thread).

The distinction ends up being useful to me. If at some point someone
points me to a specific message, and when I search for it I see the
"unread" tag, then this highlights to me that I never even looked at the
message.

> Are there any keyboard bindings to go forwards to the next message or
> backwards to the last message without marking anything as archived?

As mentioned by someone else, you can navigate the messages in a thread
with 'n' and 'p'.

One of the obviously missing keybindings is a way to easily navigate
From the current thread to the next thread without archiving the current
thread. We should probably add that keybinding at some point, but I want
to at least point out why I didn't create it originally:

The lack of a "move to next thread" binding helps encourage me to form
good habits. The goal I have when processing my inbox is to get
everything *out* of my inbox. I can do that by deciding one of several
common things:

    * I have nothing to do

	In this case I should just archive the message immediately

    * I can deal with this message "on the spot" (such as a quick reply)

	In this case, I should deal with the message, then archive it

    * I can't deal with this now, but need to later

	This is the key scenario. The wrong thing to do is to leave the
	message in my inbox, (that just makes things pile up and makes
	my future inbox processing slow, demotivating, and
	unreliable). The right thing to do is to tag this message in a
	way that I'm sure I'll find it again when I will be equipped to
	deal with it. And then I can archive the message.

So the right answer always involves archiving the message nearly
immediately, (at most after a quick reply or so), and the keybindings
encourage archiving over leaving the message in the inbox.

Of course, one does have an existing keybinding for "move to next
message in thread without archiving"; it just consists of three key
presses:

	'q', 'n', Enter

At that's long enough to discourage its frequent use.

So that's a bit of my philosophy and methodology. But like I said, we
should probably add the obviously missing keybindings so people with
other philosophies and methodologies can use the program comfortably.

> Also, just something I have noticed it isn't really obvious that a
> thread has replies without scrolling down, and that takes time. Would
> be really good if there could be some big/highlighted visual indicator
> that there are still unread messages further down.

That would be good, yes.

-Carl

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110629/b18c28fe/attachment.pgp>