[Design] view/filters: default option

[ed at atnet.at]

> I propose that when Chandler installs, it comes with a configuration
> that presents information in a novel, useful format that I will
> describe here.  This probably shouldn't be the default configuration,
> but it should be easy to select.
>
>
> I believe that people want to see their "to-do" items in their inbox,
> in priority-ordered groupings, as I discuss in
>    http://lists.osafoundation.org/pipermail/design/2002-November/000680.html
>


some email (Object) which needs a "To-do" has the attached attribute
"to-do"

If someone did receive something and didnt yet look at it, then it
has the attribute "inbox" which means you should look at it.

If you select now all objects (=emails) with the attributes "inbox"
and "to do", then you get all your to-dos in the inbox.

But it would be also ok just to look at all to-dos.

[snip ed]
>
> My readers and clients have found a configuration like this to be very
> useful:
>
> + New messages go into the inbox.

all new items sent to a person get the attribute "inbox" until this
attribute is deleted by the person itself.

>
> + Messages are in groups.  Each group can be expanded/collapsed by
> clicking on a plus/minus symbol, right-pointing/down-pointing
> triangle, whatever.
>

this is not needed in my concept. It leads to the concept that
there is a tree hierarchy between group and person, which it
not necessary.


> + At the top are groups of people in address books.  All messages  from
> people who are in the X address book are in the X group.
>

People are represented by an Object. This Person Object can have the
attribute that is is "a friend of mine", but it can also at the same time
have the attribute "i do play tennis with this person" and
"this person belonges to the people living in new york"

When I look for a tennis partner, then I set the filter to (all Objects with
the attribute "I do play tennis with this person")

When I would put people in groups, I would need to put them in many groups.

When I would get a message from this person, I would have all messages from
them in all group boxes. This is soemting I dont want.

> + Groups are displayed in the order of the address books, whatever  that
> is.  (Alphabetic works for me.)
>

Just set a filter, you get a list of all objects fulfilling this filter.
Then just sort the list by any other attribute you want on the fly.

> + After the groups of people in address books are messages that are
> non-spam from strangers (unrecognized addresses).
>

Well, each mail i receive from a person I have in my database gets
automatically the attribute "from a person i know"

I set a filter to "display me only Objects from person I know", And dont
see any spam at all.

> + After the strangers' messages are groups for each mailing list, one
> group per list.
>

How about setting the filter at "show me all messages of this mailing list
from people i dont know"

> + After the mailing list groups comes stuff that is borderline spam  --
> messages that have a spam score that is lower than some threshold.
>
> + Messages with a spam score that is higher than the threshold are  not
> visible (deleted, in a different folder, or hidden).
>
> + There are three (or four) buttons somewhere: "Dismiss", "Show next
> message", "Delete", and, if there is adaptive spam filtering, "This  is
> spam."  ("Dismiss" is discussed in a different thread.)
>
> This is essentially the strategy that I recommend in my books; those
> who have implemented this strategy report a 25%-75% time savings on
> email.  (Okay, okay, all but one, who had a relatively light email
> load.)
>
> Note that the grouping here is by sender, not by project.

With my concept you could do grouping by whatever you want.

As I undestand, you just propose a setting of how the standard view
should be configured.


I've found
> that grouping by project is very hard to do.  (Even people don't know
> what to do with messages that mention two different projects.)

Well, how about given an message two attributes:
"has to do with project X"  and "has to do with project P"

I prefer to work with projects, because you can work on different projects
with the same people :-)

> However, there is always one and only sender of a message, and people
> *TEND* to be in different identifiable groups.
>

Not always.

> Yes, yes, I know that your friend Joe is in your "Work" group *and*
> your "Friends" group.  But doing *some* categorization is a lot
> better than doing none.  And, depending upon how Chandler does
> things, you could conceivably have Joe in two different address books
> so that his message shows up in two different groups.  (Dismissing  one
> of Joe's messages should dismiss both.)
>

Sorry, I do have one friend Joe, and having him in two Adress books means
having to update two entries when he changes phone number.

I prefer to have one Object relating to Joe, with the attribute
"is my working partner" and "is my friend"

>
>
> For extra bonus credit, it would be handy to have a special address
> book that is automatically populated with anybody that the user sends  a
> message to.  (Dragging and dropping to their regular address book  of
> course makes it easy to populate their regular address book(s).)  Then
> you could have three groups of people automatically: "in my
> address book", "not in my address book but I have corresponded with
> them in the past", and "unknown senders".
>

Well, this would be someting your import plug inb would do.
Generate automatically an person Object with the relevant attributes and
the referers to the email object.


> I don't care how this is implemented.

I did it and it works gread.

> One way would be by including  a
> set of filters that tag all messages with a category.  To do this,
> however, you'd need two additional, flexible filter actions "assign  to
> category of same name" and two new filter conditions "is in any  address
> book" and "is a mailing list":
> 	if incoming message sender is in any address book
> 	then assign message to category of same name as address book
> and
> 	if incoming message is a mailing list
> 	then assign message to category of same name as mailing list
>
> If you are willing to expose Chandler's address book to an external
> executable, you could have the executable do all the magic:
> 	if true
> 	then execute script categorizeMessages.py
>
> Both of these feel slightly kludgy to me.
>
> It could also be a very specialized View, one that knows about
> address books.  I actually like this implementation best, because  it's
> completely non-destructive and potentially easy to find.  Users  can
> flip back and forth between this "magic" view and "show all
> messages" or "show all unread messages", whatever.
>


I think you get an understanding of how database filter based Object
handing is supposed to work.

> Doing this as a View also makes it easy for those of us who like to
> write filters to customize it just exactly the way we want it.
>
> Obviously, Chandler won't die if this isn't implemented, but I
> *strongly* encourage you to consider providing this view or something
> like this.  As I said, the feedback I've gotten is that this buys you
> 25-75% of email time savings.
>
> For an academic paper on organizing an inbox by category, see
> 	Google-Lucky: "bifrost inbox organizer"   (the paper has a long URL)
>

As I said, I think just categorisinig emails ist just not enough.

The best technology to implement this would be the database driven
file system like reiser4

Yours

ed


> --
> Kaitlin Duck Sherwood
> Author of the _Overcome Email Overload_ series,
> http://www.EmailOverload.com _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design