[Design] Outbound rules

[Nick Virtue]

Dave Weinstein wrote:
 > Automatic Threading can become really troublesome at times. What 
happens if
 > you have seperate mail folders for each of the friends that you 
correspond
 > with, you start a "conversation" with one, and he joins in another?

If Chandler is sorting things into folders, then I agree with you. My
understanding of the "views" that Chandler is going to use means that
there would be only one copy of an email, but it may turn up in many
diferent views. You would have a view for "any communications with
friend A" and another for "friend B" so there would be some crossover.
But being able to see your replies right along side the message you are
replying to (Like most IM's, IRC etc) for email would be fantastically
useful ...... non-trivial to implement successfully tho ... :)

 > Or do you blow off having filters and have
 > the "folder tree" represent realtime (possible overlapping) sets of 
filtered
 > messages that are still kept in your inbox (so that the message 
thread shows
 > up in BOTH, "folders" for each friend even though there's only one 
actual copy
 > of the message in your inbox...)

Basically yes. People here have been talking about message "filters"
actually asigning properties/points/categories to messages, and then the
views pick up messages based on these.

Brian Siano wrote:
  > In regard to threading... couldn't that be handled with judicious use
  > of autoassigns to the data fields? For example, one auto-assign might
  > be to a data field that contains the previous message in the thread.
  > And if the user filters his Email view by this field and sorts by a
  > "Date Arrived" or "Date Sent" data field, he or she'd have a perfectly
  > decent message "thread."

I would like to see it working something like this.

N.

 > -dw
 >
 > Nick Virtue wrote:
 >
 >
 >>>Actually -- that's one of my favorite Outlook hacks.
 >>>When I press send, it searches the message for the word "attach", and if
 >>>there aren't any attachments, it asks "Are you sure you didn't have
 >>>anything to attach to this?"
 >>>
 >>>Sure, it's a little redundant sometimes ("No, I won't sell that baseball
 >>>card, I'm attached to it"), but it sure saves the D'Oh! factor when I'm
 >>>sending out proposals, documentation, etc.
 >>
 >>If the software was designed in a more goal orientated way, this
 >>wouldn't be a problem: you are actually trying to send someone a file
 >>(your goal), instead of sending an email and attaching a file (one way
 >>of achieving that goal) ..... so if chandler took this approach, you
 >>would request to send "x" file to "Y" contact, and you could optionally
 >>provide some text (note) to go along with this.
 >>
 >>Under the hood, chandler can send this however it seems best .... email.
 >>p2p, etc .......
 >>
 >>I've seen it mentioned elseware that IM's and emails should be handled
 >>in the same manner, I 100% agree. All communications with another person
 >>should be visible together, both incomming and outgoing, so you can get
 >>an overall picture of the "conversation" you are having with them. I
 >>hate the way all email apps (I have used) seperate incomming email and
 >>your replies.... it sounds like Chandler will be able to handle this
 >>very easily.
 >>
 >>Seeing as this is my first post, an intro:
 >>
 >>My name is Nick, I live and work in New Zealand as a User Interface
 >>Design Consultant. I've been a programmer for about 15 years, now mainly
 >>working in Java, both client/server side, web based and stand-alone
 >>applications.
 >>
 >>Nick.
 >>
 >>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 >>
 >>Open Source Applications Foundation "Design" mailing list
 >>http://lists.osafoundation.org/mailman/listinfo/design
 >
 >
 >
 > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 >
 > Open Source Applications Foundation "Design" mailing list
 > http://lists.osafoundation.org/mailman/listinfo/design
 >