I like 'Send as' better as well. If there are no objections, I
propose we change the 'Send via' to 'Send as'. :o) See more in-line
On Nov 16, 2006, at 10:07 AM, Grant Baillie wrote:
On 16 Nov, 2006, at 00:15, Davor Cubranic wrote:
Brian Kirsch wrote:
Perhaps I misspoke. In Chandler, the From field doesn't
necessarily have a valid email address. It could just be text.
The "Send via" field is what would normally go in the "From"
field of a traditional email client.
In normal email clients, recipients of Chandler messages will
see the email address in the "Send via" field appear in the
"From field".
Honestly I don't see what you are trying to accomplish here. A
email message in a traditional mail client must have a from with
a valid email address. It can't just be text. If the Send Via is
normally what would go in the From field then lets put that in
the From field. We still have to support traditional email
clients so why are we reinventing the wheel here?
I think Mimi is trying to make the distinction between "from" and
"reply-to" headers a little less jargony. One could perhaps argue
that it is more natural to let the user just say "Send as", and
then behind the scenes map that value to the "from" email header
and the account address to the "reply-to" header.
I'm certainly a fan of less jargon. But this feature is more core to
the design than addressing technical jargon. It is essential to our
way of allowing Chandler users to collaborate on items with each
other and non-Chandler users in a single workflow by using email as
the 'universal' transport mechanism.
As a result, we find ourselves in the funny situation where we're
bastardizing the meaning of 'From' and 'To' by using them the way you
might use 'Organizer' and 'Participants' for Events or 'Requestor'
and 'Requestee' Tasks. When editing and sending updates about changes
you've on an event, you would never want to change who the
'Organizer' was of an event, just because one of the participants
happens to be the person 'sending' an update about the event. The
persistence of the 'From' and 'To' metadata is what distinguishes the
Edit/Update workflow from normal Replies Forwards, which DO change
the 'From' and 'To' fields.
In the past we have considered designs that would automatically
change the 'From' and 'To' fields to be called different things
depending on what stamps have been activated. But this is actually
quite complicated. If an item is a Task on the Calendar, should it be
Organizer and Participants OR Requestor and Requestee? What if I've
entered an office holiday on my calendar and decide to send it to the
entire office? Should it really say that I organized the office holiday?
So, we decided to first try 'From' and 'To' which are generic and
potentially confusing as Grant pointed out, because of email, but
it's the simplest design and certainly worth a try before discarding
it for a more complex one.
My understanding of the design is this: When Chandler is displaying
an invitation, i.e. an event stamped as an email, the main focus is
on the event, i.e. who is organizing it, who is attending, who is
being notified (but isn't attending). The fact that the invite is
being transported via email is secondary; in fact, if the item is
shared, some of the people in the addressing fields will find out
about it via syncing a share instead of email. You can also imagine
a future Chandler where the invite is transported via other
mechanisms (jabber, atompub, CalDAV scheduling, ...).
So, that is what the design was designed to support. You can still
get at the email fields via a menu item, but that's not enabled by
default. One point of contention, that we discussed in the past,
was that users might find the new use of the terms "from", "to",
"cc" confusing. This may well be possible, but really we won't know
for sure until we've gotten the app in the hands of real users.
...
P.S. "Send via" sounds really awkward. How about "send as"?
Personally, I think I prefer "send as" slightly. However, I'm not
totally enamoured with either (not being totally enamoured with
terminology seems to be a recurring condition for me, though :).
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
