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

List:       kmail-devel
Subject:    Re: Sieve support in KMail
From:       Heiko Hund <heiko () ist ! eigentlich ! net>
Date:       2005-06-06 21:51:24
Message-ID: 200506062351.24840.heiko () ist ! eigentlich ! net
[Download RAW message or body]

On Monday 06 June 2005 22:33, Martijn Klingens wrote:
> On Monday 06 June 2005 21:34, Andreas Gungl wrote:
> > Am Montag, 6. Juni 2005 21:11 schrieb Heiko Hund:
> > > Do you really want to go there? I think it will be hard to develop
> > > and even harder to understand for the user. I understood the idea
> > > that filters are transparent to the user, that she doesn't need to
> > > care where the filters are stored, but somehow get a itch from the
> > > idea. After all sieve filters should not be confused with local
> > > filters. Mixing them together in one dialog will IMHO cause a lot of
> > > confusion. What are your feelings about a separate dialog for the
> > > sieve stuff (just like we did it with pop-filters back then)?
> >
> > I share this POV. Mixing the capabilities of sieve filters and local
> > filters in one configuration frontend will make the user helpless. You
> > have vacation and bounce on the sieve side, execution of scripts or
> > piping through filters on the other (local) side. You could mix both
> > worlds in the GUI and you'll never know what will end on the server.
>
> You guys are thinking too technically :)

We _are_ technically technically =P

> From a user perspective you just want to create a filter, period. Whether
> it's a POP3 filter (wth is that a separate menu entry?), an IMAP filter,
> procmail, or whatever doesn't matter the least.

Generalisation is a good thing where it occurs naturally, I agree this far. 
But here none of the filters have stuff in common (ignore the common subset 
for me, would ya) except that they are called filters. Sieve filters (lets 
call them so) get applied when a message arrives on the mailserver. Pop 
filters before the messages get downloaded from a server and local filters 
after they arrived locally. Another difference is that sieve scripts are 
stored centrally where the other two are stored locally. Also sieve scripts 
are per (imap) account the others are IMHO per installation.

> The only distinction that you *may* want to make is whether a filter runs
> on the server or not, and Thomas Zander was IMO right at the PIM meeting
> that even that is too much asked in general.

Hiding details where possible and useful is the right thing to do. But I 
don't see that rule applicable here. As the technical guy I know what I 
want and I choose the right dialog for that. If I only know that I need a 
filter and I know nothing about POP3, IMAP and/or fetchmail how should I 
choose the right settings for my unified filter? Why can't I store the 
filter on the server? I have a POP server I get my mail from, but the entry 
stays greyed out... seems I need to RTFM. My point: why should the fine 
manual not be consulted _before_ making a filter (if unsure).

You'll piss off users who know their stuff, plus you hide information from 
the one who don't. That is one thing I always disliked about Windows(tm). 
You don't have to know a thing to get started, and you'll probably get 
around after learning some GUI, but you'll never understand the concept 
behind it. And in this very case we are discussing the concepts differ 
much. I think any user who cares for filters will be willing to learn about 
the different types of filters there are (they are not too much for an 
overview). That keeps the interface clean and comprehensible. (I'm sorry I 
had to mention Windows in this paragraph)

Also the technical and not so technical users gain from this approach. The 
is no need to subset functionality of one specific filter. In your first 
mail you had to mention so many exceptions for the 'unified filter dialog' 
because the filters are not compatible. Keeping them apart will IMHO do 
them good.

> So far however my opinion, and Thomas'. Now there's also two opinions
> against, so could one of you elaborate why a user would feel helpless
> instead of helped?

Hmm, good point. The more advanced users will probably feel helpless, 
betrayed and get laughed at by the guys in the office that always told them 
to stick with mutt. =) The less advanced users will probably cope, 
understanding the dialog instead of the concept. I as a techie say: nay. 
Can't really speak for the not so techie people, but think they should be 
able to differ between the types of filters.

Could you sketch a unified filter dialog in words for me? I imagine it 
overloaded with radios and checkboxes for the exceptions, many of them 
grayed out since the currently chosen protocol doesn't support a feature.

Regards
Heiko
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]