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

List:       kmail-devel
Subject:    Re: Sieve support in KMail
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2005-06-06 22:44:19
Message-ID: 200506070044.21259 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 06 June 2005 23:51, Heiko Hund wrote:
> 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.

We are obviously not talking about the same kind of user. The normal 
user just wants to setup filters. He doesn't want to think about 
whether he should setup a filter on the server or locally. In fact he 
doesn't even want to know that there's a difference (which is where it 
gets difficult). What he might want though is that his mail is also 
filtered when he accesses it through a webmail frontend or from another 
location (which is the second hard problem).

Martijn mentioned that some icons would show whether a filter is stored 
on the server or not. So the user will know what will end up on the 
server. He will be informed that some filters can't be executed on the 
server and he will be given advice how to fix this. One "easy" solution 
for the user is to reorder the filters, i.e. move filters which can be 
uploaded in front of filters which can't be uploaded (which is only 
easily possible if all filters are shown in the same list and thus the 
same dialog). Note that KMail can't automatically reorder filters 
because there's no way for KMail to know whether a filter depends on 
another or not. (FWIW, this is comparable with the current situation 
with spam filters where the user can move some filters before the spam 
filters in order to reduce the amount of unnecessarily checked 
messages.)

> > 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.

Let's ignore POP filters in this discussion. (They have a completely 
different purpose and are IMO rightfully configured in a separate 
dialog.)

Server-side filters and local filters have mostly the same purpose. The 
purpose is to act on incoming mail (on the server or locally) and 
mainly to sort incoming mail into different folders.

> > 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?

Well, that's exactly why it should be setup in the same dialog. You 
don't need to choose any right settings because KMail decides for you. 
And if it can't decide then it might ask for your assistance.

> Why can't I store the filter on the server?

KMail will explain if you click on some yet-to-be-decided GUI element. 
(Thomas proposed a flat button.)

> 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).

As soon as the user needs to look in the manual we have already lost. 
The goal is to design an application in a way that the manual is mainly 
unnecessary.

> You'll piss off users who know their stuff, plus you hide information
> from the one who don't.

We definitely don't plan to do the latter. And people who know their 
stuff are probably anyway better off with a dedicated application for 
Sieve filter management.

> 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.

Users don't want to understand concepts. They don't want to get a degree 
in computer science. They just want to use this fscking application to 
get their work done.

> 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.

That's where we disagree. Without actual user testing which 
OpenUsability.org will most likely do for us if we ask them nicely we 
have no way to know. But before something can be tested it has to be 
implemented. I suggest we start with the common dialog.

> > 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.

You imagine wrong. AFAIU Martijn at the KDE PIM meeting the dialog will 
basically stay the same as it currently is in svn trunk. The only 
difference will be some kind of indicator for local/remote filters. The 
changes will mainly be in what happens in the background, i.e. that 
KMail will upload some filters. I think Martijn didn't yet know what to 
do with filter criteria and filter actions which are supported by Sieve 
but not by local KMail filters. (The other way around is no problem.)

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]