[Design] [Sum] Decoupling In/Outbound mail accounts
mimi at osafoundation.org
Wed Feb 8 18:11:15 PST 2006
(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
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
+ 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
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.
>>> + 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
> 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.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Design" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Design