[Users] [Bulk] Re: Claws config needs much better documentation

[Michael Gmelin]

On Mon, 30 Jul 2012 18:16:36 -0400
Steve Litt <slitt at troubleshooters.com> wrote:

> On Mon, 30 Jul 2012 23:39:08 +0200, Michael Gmelin said:
> > 
> > 
> > On Mon, 30 Jul 2012 17:08:56 -0400
> > Steve Litt <slitt at troubleshooters.com> wrote:
> 
> > > Fair enough, but when a part of the program departs from the
> > > behavior norms of user software, for gosh sakes, DOCUMENT IT, and
> > > document it prominently.
> > 
> > Well, Claws deletes the currently selected message - which is
> > standard behavior for UI applications. Moving the cursor keys does
> > not open a mail, but changes the selection
> 
> That behavior is configurable. The surprising part is, if you
> configure it to not pull the body on changing the message, instead of
> blanking out the body of the previous message, it keeps the body of
> the previous message.
> 
> >  - which is standard behavior for many
> > file managers and other programs where changing the selection does
> > not open a file. It might be unusual for a mail client - but then
> > again, clicking an email actual opens it, just moving the selection
> > with the cursor keys doesn't. I don't quite understand how somebody
> > could just not realize this immediately - I mean you are using the
> > cursor keys and realize that the selection changes, but the mail
> > shown doesn't. It's very obvious and I doubt that anybody who is
> > not getting this will actually read the documentation before
> > stumbling over this (who is reading documentation software before
> > using a program these days anyway
> > - if ever, unless they hit a problem which would be too late in this
> > case).
> 
> As someone who accidentally deleted because of this, let me explain
> how it happened. First, I get 500 nonspam messages a day, so I move
> fast. My mental algorithm for deleting a message is that if I see
> anything in either the body or the subject indicating I'm not
> interested, I just press d. Also, keep in mind my desktop Claws is
> configured to pull the body upon highlighting the current message. So
> I deleted a piece of spam after reading both the subject and the
> body. The highlight moved to the next message, but I was still
> looking at the body, and saw it waas the same. A quick look at the
> subject showed it and the sender different, and I thought "Oh, one of
> those virus-generated spams that changes its subject every time", and
> pressed d again. After four of these I was thinking it's a pretty
> prolific virus. After five, I realized I had skipped a step
> somewhere, went back, undeleted the messages, and discovered the
> bodies changed when I pressed Enter or clicked the message.
> 
> > 
> > That said, I have a very simple suggestion that might solve this and
> > increase usability at the same time - it definitely would get the
> > attention of new users so that they understand that something's
> > different:
> > 
> > Change the message list, so that the mail currently shown in the
> > message pane is marked as well as the currently selected mail. Keep
> > the standard selection color in case both refer to the same mail
> > (selected mail is also the one shown). When moving the selection
> > using the cursor keys, keep an outline around the currently shown
> > email and use a different color for the selection bar. If you hit
> > enter, the previously shown email gets deselected, and the selected
> > entry uses the normal selection bar again (I hope you get the idea).
> 
> If it were me, the only change I'd make to the "lazy body download"
> method would be that, if the highlighted message's body hasn't been
> downloaded yet, show a blank body, not the body of the previous and
> completely unrelated message.

Hm, but this is part of what makes this feature useful to me. I can
skim through the message list without losing the one open. I can also
delete and move other messages without losing what's open. All very
useful to me. Workflows can be a very personal thing :)

To be fair, I hardly ever delete emails, I am much more concerned about
marking emails as read by accident.

Maybe marking somehow in the message pane, that this is currently NOT
what is selected could help? This might also be easier to implement, in
case cairo makes the - as I learned old behavior - too complicated,
e.g. by changing the background color to a configurable value.

> 
> SteveT
> 
> Steve Litt                *  http://www.troubleshooters.com/
>                           *  http://twitter.com/stevelitt
> Troubleshooting Training  *  Human Performance
> 
> _______________________________________________
> Users mailing list
> Users at lists.claws-mail.org
> http://lists.claws-mail.org/cgi-bin/mailman/listinfo/users



-- 
Michael Gmelin