[Design] [Sum] Decoupling In/Outbound mail accounts

[Mimi Yin]

Yes you're right, From: would make more sense.

Sorry I realized I jumped the gun a little. I 
wrote up the summary but didn't ask for feedback. 
Grant, thank you for giving it anyway, even 
though technically, nobody asked for it.

>I'm a little confused: why do we want to add 
>"Reply-To" in the SMTP account dialog? Isn't the 
>thing you're typing in your email address? In 
>the context of SMTP, that's really "From".
>
>--Grant
>
>On Feb 8, 2006, at 18:11, Mimi Yin wrote:
>
>>(Next actions: Resourcing? This needs to be 
>>factored into our F/B Scheduling and 
>>Invitations phasing proposal.)
>>
>>Just talked to Morgen on the phone, here's a 
>>phasing proposal for how we're going to 
>>de-couple In and Outgoing mail accounts in 0.7:
>>
>>Phase 1: Add "Reply-to" field to SMTP account dialog
>>Goal: To get sending email usable enough that 
>>people can try stamping events as emails and 
>>send out email invitations
>>
>>Phase 2: Unify In and Outbound email account info into single Email account
>>Goal: Improve user mental model for how email accounts work
>>+ Create new email account (no distinction between In and Outbound)
>>+ Select from 3 options: Outbound only, IMAP, 
>>POP (Outbound only will be default in 0.7)
>>+ Users enter Outbound account info for all 3 types of email accounts
>>+ Users enter Inbound account info only for IMAP and POP
>>
>>Future Phases: Beyond 0.7
>>+ Get rid of "Outbound only" option from 
>>pull-down when Inbound email is usable
>>+ Store SMTP account information users enter 
>>into various email accounts so that they can 
>>re-use the same Outbound account information in 
>>multiple email accounts
>>
>>Mimi
>>
>>On Feb 8, 2006, at 5:25 PM, Mimi Yin wrote:
>>
>>>Is there a Reply-to field right now for 
>>>Incoming mail? I think the Reply-to value in 
>>>the Outgoing mail account settings could 
>>>override whatever email address was entered 
>>>for Incoming mail. In most cases, it will 
>>>probably be the same email address.
>>>
>>>This solution is just appealing because it 
>>>requires the least amount of change. See more 
>>>below about the unified account approach.
>>>
>>>On Feb 8, 2006, at 4:38 PM, Morgen Sagen wrote:
>>>
>>>>
>>>>On Feb 8, 2006, at 4:16 PM, Mimi Yin wrote:
>>>>
>>>>>We want to allow people to easily send out 
>>>>>invitations in 0.7 without having to:
>>>>>+ fill out incoming mail account information, thereby
>>>>>+ sending Chandler into the throes of trying 
>>>>>to download your email into the repository.
>>>>>
>>>>>Currently, if you fill out the SMTP account 
>>>>>information, you have to fill out Incoming 
>>>>>mail account information as well (so that 
>>>>>there's a reply-to email address for 
>>>>>outbound mail.)
>>>>>
>>>>>Here are a couple of proposals for how we 
>>>>>might de-couple incoming and outgoing mail 
>>>>>accounts in 0.7:
>>>>>
>>>>>+ Add a "Reply to:" field to the SMTP 
>>>>>account form. Allow users to send email by 
>>>>>just filling out Outbound mail information 
>>>>>without an Incoming mail account. AND/OR
>>>>
>>>>At first this one appealed to me, but then 
>>>>what happens if you create an SMTP account 
>>>>(filling in a reply-to address), and then 
>>>>create an IMAP account (also filling in a 
>>>>reply-to address).  
>>>>When you send mail, which reply-to does the mail framework use?  
>>>>You could follow the rule that if the 
>>>>IMAP/POP account you're using to "send from" 
>>>>has a reply-to address filled in then use it, 
>>>>overriding what's in the SMTP account.
>>>>
>>>>>+ Unify Inbound and Outbound mail account 
>>>>>info into a single Mail account. Users can 
>>>>>optionally fill out the incoming mail 
>>>>>server. AND/OR
>>>>>+ Add a checkbox to the mail account form 
>>>>>that is un-checked by default: Sync 
>>>>>automatically.
>>>>
>>>>Actually, unifying Inbound and Outbound into 
>>>>a single Mail account is rather appealing; 
>>>>the account edit dialog could have an 
>>>>account-type listbox with three choices: 
>>>>IMAP, POP, or  
>>>>"Outbound only", and a single reply-to field 
>>>>for the whole "account".  The only downside 
>>>>is that two Inbound accounts couldn't share 
>>>>the same Outbound account, but that's 
>>>>probably not a big deal.   This also means 
>>>>the awkward "use as default 'from' account" 
>>>>radio button gets replaced by the more 
>>>>natural "use as default mail account".  So +1 
>>>>to the unification, but I don't think we need 
>>>>the "sync automatically" checkbox if we have 
>>>>the 3-way account-type listbox I described 
>>>>(unless you include that checkbox in addition 
>>>>to the listbox).
>>>
>>>I think this approach is ultimately more 
>>>usable, since people think about email 
>>>accounts as both Inbound and Outbound. In the 
>>>future we can have something that stores SMTP 
>>>accounts so that you can reuse them across 
>>>multiple accounts, but for now, having users 
>>>enter the same info a few times is probably 
>>>okay.
>>>
>>>Do you think we need an Outbound only? We 
>>>could just make the Inbound mail server info 
>>>optional and force the user to Sync it 
>>>manually. Otherwise, I think the first 
>>>approach is cleaner.
>>>
>>>>
>>>>~morgen
>>>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>>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
>>
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>>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