Re: [Design] In Out collection logic proposal refinements

[Mimi Yin]

Hi Brian, Thank you for writing this summary. It's very helpful. I don't see anything that jumps out me. I don wonder though if for the sake of simplicity, we want to hide the In and Out collections for preview. All of this work would still go towards identifying whether any given item is In or Out, we just wouldn't show those items in  dedicated In and Out collections. (I know! After they just made a comeback in Alpha4). This will allow us to ignore many of the thorny UI questions related to In and Out, namely: + Adding and Removing items from the In and Out collections + Creating new items in the In and Out collections My feeling is, in the future we will want to support these features. We've worked really hard to break down the distinction between explicit collections and query collections and it would be shame to give up now and insert 2 query collections in the sidebar with UI  limitations that don't exist for other collections. Does that sound reasonable for Preview? Post-preview we can revisit the In and Out collections, along with the Unified Data In/Out Proposal and Spheres (e.g. Won't users want to have separate In/Out collections for their Work and Home email accounts?) Please see more detailed comments in-line... On Nov 9, 2006, at 3:05 PM, Brian Kirsch wrote: First for clarity sake, when I say the 'me addresses' I am talking about any address configured in the Account Preferences dialog. So if I have an IMAP Account with an Email Address, a POP account with an Email Address, and an SMTP with an Email Address, then I have three 'me addresses' to compare against. I will also preserve any old 'me addresses' which were entered in the Account Preferences and then changed at a later date and use them as well in the 'me addresses' comparison. I would like to refine the exact definition of the In / Out / Dashboard logic to the following: In Collection ----------------- 1. Contains all mail received via the Mail Service. Users might get into this weird situation where Email that shows up in Chandler via Sharing that is addressed to say: [EMAIL PROTECTED] won't show up as INBOUND, but Email addressed to [EMAIL PROTECTED] that shows up in Chandler via the Mail Service will.    From an user perspective, the more concrete thing to latch onto is 'Who is in the item addressed to' not how did I get the item into Chandler.  Is there an easy way to only mark email received via the Mail Service that meets Criteria #2 below? Everything else is treated as neutral? Neither In nor Out. (Not a requirement, just wondering.) 2. Contains any mail item where one or more of the 'me addresses' appears in the to or cc address. Yup Out Collection ----------------- 1. Contains all mail items composed in your instance of Chandler. What this means is it must contain one of the 'me addresses' as the from or no address if the mail accounts have not been set up. This covers the case where a user composes a mail message before entering in his or her mail account information. A user can never enter an address in the from field that is not in the 'me addresses' list. Yes, good catch. 2. Contains any mail item where one or more of the 'me addresses' appears in the from or reply address. Just to clarify: It should be 'From' OR 'Send via' field. The 'From' field is just a text field. The 'Send via' field is where the user sets which email account they want to use to send the item. The From field could be filled in with gobbledy-gook text or somebody else's email address. Dashboard Collection ------------------- 1. Contains mail composed in your Chandler. Is this the correct behavior?     Do we add all mail in the 'Out' Collection or just those you personally composed? I think we add any message items that were: + Received via Mail service + Composed in a Mine collection (including Dashboard) + Got into my Chandler repository via Sharing of a Mine collection We exclude any message items that were: + Composed in Not-Mine collections + Got into my Chandler repository via Sharing of a Not-Mine collection Of course, at any time, the user can explicitly add a message item from a Not-Mine collection to a Mine collection, at which point, that item should show up in the Dashboard. 2. Contains all mail received via the Chandler Mail Service. The sending replying rules would remain the same but be applied against the new 'In' and 'Out' collection behavior. The rules are: 1. All mail in the 'Out' collection which has not already been sent is sendable. Plus, any message that has been sent, but has since been edited, is now re-sendable. 2. Al mail is the 'In' collection is replyable and forwardable. Is there a reason to ever disallow reply and forward? so long as the item is addressed with valid email addresses? I reply to message I sent all the time in Apple Mail. I also came across an interesting bug. No matter which Tab I have selected in the Toolbar (All, Mail, Task, Calendar), if I have the 'In' or 'Out' collection selected in the sidebar and hit the New button an item of that stamping is created in the collection. This obviously not the right behavior. Ick, this would go away if we got rid of the In/Out Collections from the sidebar for Preview. I would assume going forward that this action would be disabled. The 'In' and 'Out' collections are Read only and calculated by the coder. Thus a user should not be able to drag any item in to the collection or create new items in the collection manually. I think in the future, we would want the item to be auto-stamped as a message and auto-addressed appropriately. So what should happen if a user hits 'New' in one of these collection or tries to drag an item in to the collection? What should the app do? Display a alert warning? Ignore the request? I will also post this to the design list so others may voice their input. -Brian _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 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