[Design] Comments on Email 0.7 spec
Brian Kirsch
bkirsch at osafoundation.org
Fri Feb 23 17:32:39 PST 2007
Hi Mimi,
I reviewed the latest spec. Here are the questions and comments I have.
First, you list out the various kind combination examples of what
should appear in
the body of a message. Those look good. What I am not clear on is
what should appear
in the body / subject of an item that is just stamped as a mail
message. It seems in that
case we would not want to prepend all that extra info such as kind
combination to the message.
Second, I am a bit confused on the forward case. Currently when a
user hits forward if the
original message was also an event that events info is packaged as
an .ics and sent along with
the forward. If the user then stamps the forward as an Event we send
both the original mails .ics and
the forwards .ics.
How is this suppose to work with EIMML?
Are we suppose to package the original messages EIMML? What advantage
would that be?
If you could provide more detail in the forward case to exactly what
EIMML and .ics are suppose to
be attached to the forwarded message that would be a big help.
I also not clear on this statement taken from the spec:
Chandler will add: Begin forwarded <KIND-COMBINATION>: to the top of
the Notes field, 2 line breaks down from the top of the Notes field.
For a list of all the possible Kind-Combinations, please see both the
'Sending Items' and 'Receiving Chandler Items in generic email
clients' section above.
Is the kind-combination based off the original message or the
forwarded item?
See the rest of my comments inline:
Thanks,
Brian
On Feb 23, 2007, at 6:18 AM, Mimi Yin wrote:
> Hi
>
> I went to update the Email spec with this stuff and I ran into a
> few more wrinkles. I attempted to iron them out :o) and this is
> what I ended up with...is this reasonable for Preview? (I've also
> logged a bug to track this issue: https://
> bugzilla.osafoundation.org/show_bug.cgi?id=8209)
>
> What appears by default in the byline?
>
> For non-message items: Created by, Edited by
>
> * Full Name associated with 1st Sharing account; if there are
> no Sharing accounts;
> * Don't show the byline
Sharing accounts don't have an Email Address or Full name associated
with them. They do however have a username.
>
> Open issue: What if the user has multiple Sharing accounts and the
> same item is shared on multiple accounts?
>
> For draft message items: Send as, Edited by
>
> * Email address associated with 1st Outgoing email account user
> has successfully filled out; if there are no Outgoing email
> accounts...
> * Email address associated with 1st Incoming email account user
> has successfully filled out; if there are no Incoming email accounts;
> * Email address associated with Sharing account; if there are
> no Sharing accounts;
> * Don't show the byline
I don't fully understand this logic. But I do have an alternate
suggestion. Today, I checked in
code to smartly find the me address in Chandler. If there is no me
address filled out in the
default incoming account (which is the primary value used to
determine the me) I now scan
all mail account till I find an Email Address and return that
instead. The order of the scan is
search all IMAPAccounts then POPAccounts then SMTP Accounts.
So calling EmailAddress.getCurrentMeEmailAddress(view) will return
the closest approximation of
what the me address is. It seems this same logic should be leveraged
for the Send as, Edited by instead
of what you have listed above. It should be noted that what you
detailed and what getCurrentMeEmailAddress return are pretty much the
same. The difference is in the search order.
Chandler has always used the email address in the default incoming
account as the me address so we
should keep this consistency.
Also as stated above Sharing Accounts do not have a user defined
email address associated with them.
> * Note: If you receive a Draft item via server sharing,
> Chandler does not change the Send as / Edited by field to your
> email address unless you actually click into the Draft item and
> make an edit.
>
> For sent/received message items: Sent by, Updated by
>
> * Email address the item was sent with.
>
> Mimi
>
> On Feb 21, 2007, at 1:31 PM, Brian Kirsch wrote:
>
>>
>> On Feb 20, 2007, at 3:54 PM, Mimi Yin wrote:
>>
>>> Forwarding this to the design list...
>>>
>>> Yea, there was a lot of hand-waving in the area of how to deal
>>> with 'default' outgoing mail accounts.
>>>
>>> A simple solution for Preview might be: Just use the first SMTP
>>> account in the Accounts dialog.
>>
>> We already do that. The first account is the default Outgoing
>> Account. Aparna's issue is that she decided to add another account
>> instead of filling in the existing one. Others will certainly do
>> the same as well.
>>
>> Options are use the first SMTP account that is filled in if the
>> default is not filled in or do not ship default accounts and let
>> the user manually create them or add back the ability to select a
>> default.
>>
>>>
>>> bkirsch, would this be hard? Whenever possible, reply to and
>>> forward messages with the email address the original message was
>>> sent to.
>>
>> I am not following what you are asking here. We do the standard
>> actions on reply and forward that all other email clients do.
>>>
>>> However, Chandler has weird scenarios like: User replies to a
>>> message in a shared collection that wasn't even sent to
>>> them...that make trying to guess the 'right' default difficult.
>>>
>> We can never guess the right default. Because we don't know what
>> the user wants at any particular moment.
>> All we can do is either use the default or find the first filled
>> out account. Anything other than that is beyond the scope of Preview.
>>
>> -Brian
>>
>>> bkirsch, any thoughts?
>>>
>>> Mimi
>>>
>>> On Feb 20, 2007, at 5:16 PM, Brian Kirsch wrote:
>>>
>>>> The issue of what is the default is still in need of some
>>>> refinement.
>>>>
>>>> The basic idea was to get rid of the additional fields need to
>>>> select a default.
>>>>
>>>> In your case the default account was "Outgoing Mail" which is
>>>> the pre-installed account.
>>>>
>>>> The only way to override the default is via restore settings.
>>>>
>>>> There is no way from the UI to say use account X rather than
>>>> account Y as the default for sending mail.
>>>>
>>>> I can certainly add code to check if the default account does
>>>> not have account info to
>>>> use the first smtp account that does.
>>>>
>>>> Mimi what are your thoughts on the default?
>>>>
>>>> Brian
>>>>
>>>>
>>>> On Feb 20, 2007, at 1:35 PM, Aparna Kadakia wrote:
>>>>
>>>>> I notice that we have made some changes to the Accounts dialog
>>>>> in this release.
>>>>> We used to let the user choose what smtp account(outgoing mail)
>>>>> they would like to pick for the imap (incoming mail) account.
>>>>>
>>>>> I have run into an issue and would like to know if this is a
>>>>> bug or by design.
>>>>>
>>>>> I have setup imap and an smtp accounts in my Chandler.They are
>>>>> named "demo4 imap" and "demo4 smtp"
>>>>> I also have "Outgoing mail" which is not set to anything.
>>>>> When I compose an email and try sending it I get an error:
>>>>>
>>>>> "Account set up
>>>>> The following account(s) need to be set up:
>>>>> - SMTP (outgoing email)
>>>>> Would you like to enter account information now?"
>>>>>
>>>>> Why doesn't it pick the "demo4 smtp" account I have already
>>>>> set. I don't see a place where I can set this to be the default
>>>>> SMTP account.
>>>>>
>>>>> Let me know,
>>>>> Aparna
>>>>
>>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070223/1940e25c/attachment.htm
More information about the Design
mailing list