From kmail-devel Mon Jun 06 22:44:19 2005 From: Ingo =?utf-8?q?Kl=C3=B6cker?= Date: Mon, 06 Jun 2005 22:44:19 +0000 To: kmail-devel Subject: Re: Sieve support in KMail Message-Id: <200506070044.21259 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kmail-devel&m=111809787325403 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0329685463==" --===============0329685463== Content-Type: multipart/signed; boundary="nextPart1245868.QVPvyxZgTf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1245868.QVPvyxZgTf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 user just wants to setup filters. He doesn't want to think about=20 whether he should setup a filter on the server or locally. In fact he=20 doesn't even want to know that there's a difference (which is where it=20 gets difficult). What he might want though is that his mail is also=20 filtered when he accesses it through a webmail frontend or from another=20 location (which is the second hard problem). Martijn mentioned that some icons would show whether a filter is stored=20 on the server or not. So the user will know what will end up on the=20 server. He will be informed that some filters can't be executed on the=20 server and he will be given advice how to fix this. One "easy" solution=20 for the user is to reorder the filters, i.e. move filters which can be=20 uploaded in front of filters which can't be uploaded (which is only=20 easily possible if all filters are shown in the same list and thus the=20 same dialog). Note that KMail can't automatically reorder filters=20 because there's no way for KMail to know whether a filter depends on=20 another or not. (FWIW, this is comparable with the current situation=20 with spam filters where the user can move some filters before the spam=20 filters in order to reduce the amount of unnecessarily checked=20 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=20 different purpose and are IMO rightfully configured in a separate=20 dialog.) Server-side filters and local filters have mostly the same purpose. The=20 purpose is to act on incoming mail (on the server or locally) and=20 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=20 don't need to choose any right settings because KMail decides for you.=20 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.=20 (Thomas proposed a flat button.) > I have a POP =20 > 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.=20 The goal is to design an application in a way that the manual is mainly=20 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=20 stuff are probably anyway better off with a dedicated application for=20 Sieve filter management. > That is one thing I always disliked about=20 > 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=20 in computer science. They just want to use this fscking application to=20 get their work done. > And in this very case we are=20 > 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=20 OpenUsability.org will most likely do for us if we ask them nicely we=20 have no way to know. But before something can be tested it has to be=20 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. =3D) 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=20 basically stay the same as it currently is in svn trunk. The only=20 difference will be some kind of indicator for local/remote filters. The=20 changes will mainly be in what happens in the background, i.e. that=20 KMail will upload some filters. I think Martijn didn't yet know what to=20 do with filter criteria and filter actions which are supported by Sieve=20 but not by local KMail filters. (The other way around is no problem.) Regards, Ingo --nextPart1245868.QVPvyxZgTf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCpNHFGnR+RTDgudgRAnNvAKCV2FUXSsC8C259wHxAqxNIDdxUpwCgscH3 0g3N3jiW64Yjnmq570fp58Y= =bZ6T -----END PGP SIGNATURE----- --nextPart1245868.QVPvyxZgTf-- --===============0329685463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KMail developers mailing list KMail-devel@kde.org https://mail.kde.org/mailman/listinfo/kmail-devel --===============0329685463==--