| Hi Mimi, See comments in line. On Nov 10, 2006, at 7:22 AM, Mimi Yin wrote: 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.
Well I can't say that I completely understand that decision. To me, it seems better to have at least a simplified version of the In and Out collections that are read only then to have nothing at all.
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).
Well as I have only started the implementation I do not see much point in driving forward if the work is not going to be visible in Preview. I can save what coding I have done locally to be used as a reference when this issue is addressed at a later date.
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
If the collections are Read Only then at least for Preview there are no thorny issues.
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.
Yes, I can see your point here but am still not convinced that getting rid of the In and Out collections is the right decision.
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.
Ok well this brings up a good point. In previous discussions you mentioned the design team wanted to have all mail received via the Mail Service to appear in the In collection. The reason for this decision was mailing lists. A message sent via IMAP to the [EMAIL PROTECTED] list, which the user subscribes to, would not appear in the In collection since the to or cc did not matched the me address. 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.
Yes, but this will cause things that are actually sent to the user via mail but not addressed to the user from appearing in the In Collection. Is this now the desired behavior?
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.)
Sure, it is easy enough. 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.
First, we still can not ignore the Reply-To address. This address takes precedence over the From address in traditional mail applications. The Out collection logic should verify that either the Reply To or From address matches the me address.
Ok lets flush out this Send via workflow because it has similarities to Reply-To.
The classic case seems to be Ester sends a mail message on behalf of Mitch. It looks like it is from Mitch but was actually sent by Ester.
If the receiver of the message wants to Reply that response is sent to Ester not Mitch correct?
In the Chandler world we have the Sent Via but what if the receiver of the message is using Thunderbird or Outlook. Unless we stick a Reply-To header in the message the reply would go to Mitch.
Unless I am off in my understanding of the Send Via work flow it has very much a link to the email worlds Reply-To header.
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
Sounds good We exclude any message items that were: + Composed in Not-Mine collections + Got into my Chandler repository via Sharing of a Not-Mine collection
+1
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.
Yes but is this a goal for Preview? 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.
No I think you are correct. Any valid email can be replied to or forwarded. However, currently this is not the case.
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.
Can you talk about this in more detail.
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
|
