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

List:       kmail-devel
Subject:    Re: RFC: Detecting omitted attachments
From:       Chris Kuhi <kdelists () kuhi ! net>
Date:       2002-03-01 15:16:34
[Download RAW message or body]

On Friday 01 March 2002 14:34, Marc Mutz wrote:
> On Thursday 28 February 2002 23:31, Chris Kuhi wrote:
> <snip>
> > Make it more generalized.  Integrate it into the Filters by

<snip>

> Most people don't grok the concept of filters. Indeed, constructing
> a nice set of filters _is_ programming. So stuffing everything into
> filters is IMO a no-go. It can be done so internally, but that must
> not be visible to the user.

True, but I think Volker's mail covers the 'concept' thing:
On Thursday 28 February 2002 23:41, Volker Augustin wrote:
> Just an afterthought for the distant future:
> Think of data sources, data sinks and streams connecting them. This
> represents the KMail data streams. It would be nice to have a way
> to insert filters *into* those streams that perform certain actions
> based on certain conditions. Lots of things could then easily be
> implemented as "filters" (which in turn could be implemented as
> plugins).

Given the appropriate interface I think filters can be *made* more 
intuitive.  The problem is, as you said, doing it internally where 
it's not visible to the user.  So it shouldn't make a difference to 
the user what 'filters' he has, rather he should be able to think in 
terms of categories: Mails from Mom, Business mails, mails I have 
sent to Bob, whatever.  The user wants to separate and/or sort these 
categories, and categories should not be necessarily mutually 
exclusive (e.g. Business Mails from Mom should be visible in my Mom 
folder as well as my Business folder). So that's basically Virtual 
Folders as a result, which has already been requested and I'm sure 
most people agree is needed, and will probable take a bit of 
time/effort to implement.

The point is though, from which perspective the searching/filtering 
is seen:
The developer sees mails being fetched from a server  and tests being 
performed on each mail -- one after the other -- to determine whether 
actions associated with the test are performed or not.  The biggest 
recent improvement to this IMO was the RMB->Create Filter 
possibility.  

Most users think in terms of:
a) given a mail, 'What type of Mail is this?'
b) given a 'type' of mail, 'What should happen with it and/or where 
does it belong?'
c) given a folder, 'What types of mails belong here?'

'a)' is more less filters, though some kind of graphical 
representation could really help Joe six-pack. 
'b)' is more or less the actions, though conceptually a bit more 
decoupled from the filter part.
'c)' is just an interface to a) and b) from the 'other side', namely: 
RMB->properties on a folder, and choose: show all mails in category 
'Mom' or somesuch.

Does that make sense?

regards,
-- 
Chris Kuhi
Email: chris@kuhi.net
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]