On Mar 2, 2007, at 11:34 AM, Dan Steinicke wrote:
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.
Dan, good point. I couldn't remember how I it as spelled in the spec.
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
