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

[Mimi Yin]

(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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060208/49abf840/attachment.htm