On Nov 10, 2006, at 1:14 PM, Brian Kirsch wrote:
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.
Oh, I might have misunderstood, but I think the work you're doing is central to getting the Communications status and Who columns to behave correctly in the Dashboard, not to mention the Edit and Update workflows from the Stamping Storyboards. I'm not suggesting cutting the concept of In versus Out in Preview, just the collections in the sidebar.
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.
It's hard for me to articulate all the reasons, but I just feel that the In and Out collections are a risky usability proposition and we're running out of time to
For example:
+ When the user is in In or Out, are the items themselves non-editable? I don't think we want to do that. In/Out wouldn't be truly read-only, they would be somewhere in between read-only shared collections and fully editable read-write collections.
+ When/if we have labeling (which is scheduled for Alpha 6), what happens when you remove the In/Out label from an item? Isn't that essentially the same as removing from the collection via Drag and Drop? How do we explain that some labels are removable, but others aren't?
+ I'm still unsure about the mental model for In/Out. For people who do a lot of sharing, are they going to expect that In/Out to = stuff they've receive from other people through sharing versus stuff they've shared out?
+ Will people be confused that certain messages that come in through the Mail Service don't show up in the In? e.g. BCC messages. Or will people be more confused that certain messages show up in IN because they came through the Mail Services and others don't because they came via Sharing Service, even though the messages are addressed to the same email address? (the [EMAIL PROTECTED] example)
+ We haven't had much time to experiment with these mental model issues and I'm concerned that introducing these rather tricky concepts in Alpha 5 doesn't give us enough time to collect dogfood feedback and iterate to a clean solution by Preview.
+ I'm also concerned about DnD. DnDing between collections in the sidebar is already a shaky experience today. How will making 2 collections invalid drop zones affect DnD usability?
+ I think mostly at the heart of it, I'm leery of having collections in the sidebar that can't deal with Inclusions and Exclusions. However, I'm willing to be talked out of this purist notion of what collections should be.
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.
I think there was a miscommunication here, which ended up in the spec! Apologies for that. We only want the 'me' address to affect whether something goes into the IN collection.
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?
The bonus side effect however is that in the Dashboard, messages specifically addressed to YOU will be marked differently from all other messages.
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.
Kewl.
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?
Yes. Reply-to and Send via sound similar.
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.
Yes. Sent via should = Reply To in the mail message. But, Sent via should also = FROM in the mail message.
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.
Nope.
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?
Yes, it's at the core of the Stamping Storyboards.
