Is this feature named bi-line or byline? In the email spec it is
referred to as byline. It took me longer to find this thread because I
was searching for 'byline'. It would make my life easier if we could
all be consistent with the names we use.
What happens to the byline on the received end? I did a couple quick
tests sending mail from Chandler to Chandler. I sent both a plain email
and a email stamped as an event. In both cases the items had bylines on
the sending end but no byline on the receiving end. Is this correct?
-Dan
Sheila Mooney wrote:
On Mar 1, 2007, at 8:29 PM, Mimi Yin wrote:
Hi Sheila,
Thanks for writing this up. See in-line...
On Mar 1, 2007, at 5:07 PM, Sheila Mooney wrote:
Mimi,
I was discussing this bug with Philippe since there was some
confusing interpreting your rules for what appears in the bi-line.
In an attempt to clarify for the dev team, I had a few questions.
https://bugzilla.osafoundation.org/show_bug.cgi?id=8209
So is this correct...
+ The bi-line is made up by several pieces of information including
the NAME.
I realized that there is no Full Name attribute for sharing accounts.
So its always either a sharing account user name or an email address
or Configure email account... or no byline at all.
+ In order to determine what name appears there are several
different rules.
+ If we have created or edited events, tasks and notes we use the
name from the default sharing account, right?
You mean user name?
Yup, sorry I meant username.
Ideally, when/if we have Contacts, then we can display the user's
contact name. Even better would be the ability to display a different
contact name for different 'sharing contexts' aka outbound data
streams. e.g. This item is shared with my language class and my book
club and I want to display a different 'name' for each sharing
context. But we're getting ahead of ourselves.
Exactly, I see this as temporary until we have support for contacts
which is hopefully short-term. In the meantime, this doesn't have to
be the perfect solution.
If we haven't setup any sharing accounts, we display a blank name in
the bi-line field.
Or rather, there is no byline field at all. If the user isn't sharing
and/or the item isn't addressed as a message, I'm not sure how
important it is to have that information. It just adds to clutter.
Ok, so if there is no name to display, the entire bi-line is blank.
+ For draft message items we create and edit, in place of the name
we insert...
+ The email address of the 1st outgoing email account
+ If there is no outgoing email account, we use the 1st incoming
email account name
+ If there is no incoming email account we use the username of the
sharing account
+ If there is no sharing account we leave the name in the bi-line blank.
We say: Configure email account... (which is what we do today).
+ For messages that have been sent and subsequently updated in the
name field we display the address the item was originally sent with
(before we edited).
Let me know if this is accurate per your proposal.
Questions that came up....
+ What is the rational for using the email address first in one case
and the sharing account in the other? Why wouldn't we just use the
email account name for events, tasks and notes if there is one setup.
Changing from sharing account info to the email account is a clue to
the user that addressing items and clicking Send will send things via
Email. You can imagine in the future that the pulldown contains both
email and IM account options.
So it sounds like we are trying to intentionally give the user this
context shift.
+ If we use the sharing account name for creating a new event, then
subsequently setup email and stamp as a message does the bi-line
name change to show the email account name? Would this be confusing?
Again, it's a clue to what Addressing an item to make it a message
actually does...Truthfully, I think all of this will be confusing
until we have Contacts :o(
Yup agreed and as I mentioned above, it's hopefully short-term and
perfecting it is probably not worth the bandwidth. The important piece
is that you get the feedback at all.
Of course we would always have this issue if the user didn't setup
their email accounts initially anyhow.
I also realized that there is a separate issue of what to show in the
Send as: pulldown as alternatives. I have edited the Email spec with
the following. (See bold paragraph for section what to show in the
pulldown.)
*What appears by default in the byline?*
For non-message items: Created by, Edited by
* User name associated with 1st Sharing account; if there are no
Sharing accounts;
* Don't show the byline
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;
* User name associated with 1st Sharing account; otherwise
* Don't show the byline
* 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.
*What are the options in the Send as:/Edited by: pulldown?*
*
*
* * If the user has filled out an Outgoing email account, only
show email addresses associated with Outgoing email accounts; otherwise*
* * Only show the email address associated with the Incoming email
account or the Sharing account user name. Clicking on either will
spawn the Configure email account... dialog, so there will be no
opportunity to select alternatives.*
For sent/received message items: Sent by, Updated by
* Email address the item was sent with.
Philippe, does this provide more clarity on this issue?
Hope that helps.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
