[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: KMail User Interface
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-06-01 14:59:21
[Download RAW message or body]

On Friday 01 June 2001 01:37, Ingo Klöcker wrote:
> On Thursday, 31. May 2001 14:04, Marc Mutz wrote:
> > See, you didn't read carefully. It said _threads_ (as opposed to
> > the messages they contain) are sorted by date. Yet you start
> > talking about "esp. in long [...] threads". No. I'll try again:
> >
> > _Inside_ threads messages are organized by parent-child
> > relationships. Not by subject, not by date, not by size, not by
> > sender.
> >
> > Do we agree that this is the only way to arrange messages _inside_
> > a thread?
>
> As Magnus already explained you have to decide how messages on the
> same level inside a thread have to be sorted. KMail currently uses
> the selected sorting by column for this. If you don't believe me than
> test it with this nice gigantic thread.
<snip>

One should think about why one uses threading. One uses threading to 
visualize the flow of a certain discussion in a mailing list or in a 
news group. Threfore, the only reasonable way of arranging messages in 
threads is by parent-child relations and by date when messages are on 
the same level.

> > The _threads_ are sorted by date, either descending or ascending.
>
> This is the nsmail way. KMail respects the sorting by column you
> selected even if threading is enabled.
<snip>

Yeah, and if I hit the 'size' column, because I want to check who's 
that luser that just sent me a 500K Mail, I am presented with the 
following size list:

4856
5229
4167
5493
8079
3847

See. It's absolutely useless. Yet the header shows me "Size v", 
indicating that I sort by decreasing size. I can't tell you how this 
confused me when I tried KMail for the first time.

> Maybe someone wants to sort the threads by the people who started
> them.
<snip>

What for? See, we shouldn't optimize KMail for the rare case, but for 
the normal case. I claim that the normal case of operation (if you use 
threading at all) is the following:

1. I use threading like I discussed it.
2. Sometimes I want to see who's the jack-ass that sent such big mails. 
I want to sort by size.
3. Sometimes I want to sort by date, since I want to have an overview 
of the newly arrived messages.
4. Very rarely, I might consider to change the mode of threading.

I claim that this usage pattern is valid for at least 95% of all users.

So let's analyze:

I'll base my analysis on three Kmail-models:

Current:
  Guess what?
KMail with threading tool button:
  Like Current, but I have a toolbar button that switches
  between theaded and flat mode.
NS-like KMail:
  With "thread-column" and a config-dialog with
  options for the mode of threading.

Shown is the number of  mouse clicks necessary to accomplish the 
transition:

Task	Current	toolbtn	NS-like	weight
2	5+1	2	1	33%
3	5	1	1	66%
4	1	1	ca. 5	1%
weighed
avrg.	5.29	1.33	1.04

One could argue about the weighting factors used and indeed, giving 
task 4 a weight of 10%, one obtains that "toolbtn" is more efficient 
than "NS-like". But I guess that the configuration of the threding mode 
is really something that is done once and then forgotten.

So while I'm not strictly opposed to model "toolbtn", I'd still like to 
see the "NS-like" model being adopted, simple because for _me_, the 
weights are probably more like (80,20,0), giving (5.8,1.8,1.0) as 
averages.

Marc

-- 
Marc Mutz <Marc@Mutz.com>
http://marc.mutz.com/
http://www.mathematik.uni-bielefeld.de/~mmutz/
http://EncryptionHOWTO.sourceforge.net/

_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]