Address Book Cards [ name ]

[Bryan W Clark]

There are a number of pages already dedicated to address book card fields and I wanted to work through a bunch of fields to get some discussion going about how we use them.

http://wiki.mozilla.org/MailNews:Address_Book_Card_Fields
http://wiki.mozilla.org/MailNews_Talk:Address_Book_Card_Fields
http://wiki.mozilla.org/MailNews_Talk:Address_Book

This message, as the subject indicates, is about the name field; dissecting what others are doing along with what we are doing.  Then looking at how we are using this field to understand further what we should be doing.  In general, I'm look for systems that simplify the common cases, yet are extensible enough to offer enhancing and advanced systems the ability to build and integrate upon.  Sorry this gets a bit long for an email.

Current Thunderbird
4 default and distinct fields for the name:

• First
  
• Last
• Display (generated by first and last)
  
• Nickname

Other Address Books
(this could be an en-us only view of all these systems, help appreciated)

Mac Addressbook [1]

• Name pronunciation
• First name
• Last name

Google Contacts [2]

• Title (singular - represents contacts name)
  

Yahoo Address Book [3]

• First
• Middle
• Last
• Nickname
  

Windows Live Mail [4]

• First
• Last
• Nickname

vCard [5], hCard [6]

• fn
  
• n
  
• family-name
• given-name
• additional-name
• honorific-prefix
• honorific-suffix
  
• nickname (multiple)
  

JavaPhone [7]

• N
• 0 FAMILY_NAME
• 1 GIVEN_NAME
• 2 ADDITIONAL_NAMES
• 3 PREFIXES
• 4 SUFFIXES
• FN
• NICKNAME

Naming Conventions

Many of the more complex systems are similar because they are based on the X.520 attributes, while others (like google) offer a more simplistic version.  Localization and naming conventions [8] are a very difficult problem presented to the address book naming system.  Some cultures place the Given Name [9] before the Family Name [10] (often called last name) while others place it after or use no Family Name at all. 

This tends to make the interface for names difficult because the ordering and naming needs to be completely variable depending on locale.  Not only is the UI for manual entry difficult to design, but attempting to parse up different names into the proper structure is almost always going to yield incorrect results.

Where do we get Contacts?

How does Thunderbird acquire new contacts into it's local address book.  Several methods of which most are automatic and some are manual.

• auto-collection of addresses
• manual contact entry
• import
• contact sync
  

Auto-Collection

During use of Thunderbird we expect that contacts will (by default) be automatically collected as we send messages out via reply or new compositions.  Collection brings a number of issues we don't need to discuss here, suffice it to say that we should know addresses we've collected from the ones we've entered.

Manual Entry

Manual entry by a person, typing in a name with email address uses the address book entry interface; other options are possible but not covered here.  This is the least optimal way for a person to enter their addresses into Thunderbird, it's slow and prone to lots of typos and errors.  Currently a person can enter in the First and Last name fields which auto-populates the Display Name field.  An alternate Nickname field can be entered as well.

Import

Importing contacts from other systems, LDAP, Outlook, or other address books.  Other systems use different fields for different purposes, even if we don't match their exact field naming we should try to not destroy the way they contain their information such that we can have a compatible way to export the data we imported.

Sync

Sync with PDAs and mobile devices, these like the Import often have different fields and field types which we should maintain, however our system may not use them.

Where do (and can) we use Contact Names?

Mainly we use the contact name field in searches for auto-complete in the compose window or searching the address book for a certain contact.  But currently there is no sorting by first name, last name, or other types of names.  Search is performed on all the name fields, but on them as a whole because it's generally cumbersome to do otherwise.  Separated name fields do not necessary improve search results, with an indexed database even a large set of names can be searched very quickly for the system and more importantly for the user via a single entry.

What we need to gather thoughts about

Seeing as the distinctions of first (given) name, last (family) name, and display are a bit confusing and error prone I think we should move the entry interface to only show one name type by default and allow for other name types to be entered as additional if desired.

This change will shorten up the interface to a default of 1 entry plus the [add entry] line, cutting it's size in half.  Additionally it will simplify the entry to a single line which isn't prone to internationalization differences, entries are recorded exactly as they are written or recieved and we can assume that is how they want to receive them as well.

This does not mean, however that we shouldn't hold additional first and last name data and display the differences; take for example the import or sync case.  In fact by allowing many names associated with a person but each having different types we can accomidate many more name variations mimicing what the JavaPhone or other complex systems make available.  Yet the default will still be how Thunderbird sees the name written out.

Possible XML Representation Example

All names are still a type name field such that we search across all names during auto-complete and other search usage.  During imports and syncs we keep the separations that are presented to us and search across all of them.  The likely default for most peoples address books names will be a default only.

<name type="default">Davy Crockett</name>
<name type="nickname">Davy</name>
<name type="first">David</name>
<name type="last">Crockett</name>

Possible Example Manual Entry

The Address Card entry uses a single name entry by default, but allows people to expand the names into additional columns.

Name: {  Davy Crockett  }
[ add additional names ]  e.g. nickname

Possible Example Manual Entry Edit (editing an imported contact)

If the contact Davy Crockett was imported from another system where a separation of names were given.  The contact editor added those additional name fields as separate entries but also took the full name into the default name field.

Name:           { Davy Crockett } 
[ First Name ]: { David         }
[ Last Name  ]: { Crockett      }
[ Nickname   ]: { Davy Crockett }
[ add additional names ]  e.g. nickname

This needs a lot of work, I'm hoping we can get some ideas for fixes.  Again the primary goal here is to simplify the user interface for different cultures, entry, parsing, and editing while providing an extensible system that is backwards compatible, will sync with mobile devices, and other address books while allowing for the type of interactions our system requires.

Cheers,
~ Bryan


[1] http://en.wikipedia.org/wiki/Address_Book
[2] http://code.google.com/apis/gdata/elements.html#gdContactKind
[3] http://address.yahoo.com/
[4] http://mail.live.com/
[5] http://www.ietf.org/rfc/rfc2426.txt
[6] http://microformats.org/wiki/hcard
[7] http://developer.symbian.com/main/downloads/tutorials/javaccards.jsp#CCard.CCard-005

[8] http://en.wikipedia.org/wiki/Personal_name#Naming_convention
[9] http://en.wikipedia.org/wiki/Given_name
[10] http://en.wikipedia.org/wiki/Family_name

[David Ascher]

Bryan W Clark wrote:
> This needs a lot of work, I'm hoping we can get some ideas for fixes.
> Again the primary goal here is to simplify the user interface for
> different cultures, entry, parsing, and editing while providing an
> extensible system that is backwards compatible, will sync with mobile
> devices, and other address books while allowing for the type of
> interactions our system requires.

I'd like to see at least exploration of deep support for tagging --
taggging of people, tagging of groups of people, but also possibly
tagging of field names.

--da

[Wayne Mery]

On 4/15/2008 11:15 AM, David Ascher wrote:
>...

> tagging of field names.
> --da

intriguing - in what was might this be used? (vs tagging of the person)

[David Ascher]

syncable
required
personal (things that maybe i wouldn't want to publish when I send
contact info to someone)

In general, though, the beauty of tags is that users (and developers,
see flickr's machine tags) can come up with more uses than the original
software designer.

--david

[Bryan Clark]

Right, I've talked to people who want to tag certain email addresses for
different contacts, the tag could be a project team or some other self
organization method. But it would allow you to get the right property
grouped together for a number of different contacts.

~ Bryan

[Joshua Cranmer]

Bryan W Clark wrote:
> *Other Address Books*
>
[ ... ]
LDAP (based on the schema for an intranet project at my school):
givenName = fname
sn = lname
nickname = nname = nick
middleName = mname
cn = displayName
(and probably many more if you expanded the definition of name)

This data is almost entirely imported into a script from external
sources, where the displayName is constructed on import.

> *Sync
>
> *Sync with PDAs and mobile devices, these like the Import often have

> different fields and field types which we should maintain, however our
> system may not use them.

Syncing is a gray area in this hierarchy, since it is quite possible
that the data may be data sourced from a client (potentially typed in or
"automatically" generated), modified sourced data, or brand new data; it
is quite likely that a fair amount of changes.

> This needs a lot of work, I'm hoping we can get some ideas for fixes.
> Again the primary goal here is to simplify the user interface for
> different cultures, entry, parsing, and editing while providing an
> extensible system that is backwards compatible, will sync with mobile
> devices, and other address books while allowing for the type of
> interactions our system requires.

This will probably impel a good amount of cleanup in underlying code...
the import and palmsync code badly needs this style of cleanup.

[mozil...@zindus.com]

Hi Bryan, some comments follow.

Zimbra

Unfortunately there doesn't seem to be a public normative reference for
Zimbra's contact fields. But this is what it supports:
- first
- last
- middle

In addition, the:
- fullName
field maps to Thunderbird DisplayName but it is *read-only*, and
generated by a policy, eg:
- Last, First
- First, Last
- Company
- Last,First (Company)
- etc.

The way to change this "read-only" field is to write to first, last and
middle. fullName is generated according to policy.

One can easily imagine policy-generated DisplayName being a feature that
the enterprise market might insist upon. So I wonder how this way of
thinking about DisplayName sits with the proposal to drop first/middle
from the capture interface?

It might be good to have a use-case around this. ie. how would a user
edit a contact's name when their addressbook was synced with a company
using policy-generated DisplayName.

Differences between the vendors

In terms of subdividing DisplayName, the odd one out seems to be Google.
All the rest support the up-front capture of (at least) first and last.

One can certainly imagine displayName-only capture offering more uniform
semantics across western and non-western cultures. Presumably that's
the choice Google made. But I do wonder whether displayName-only
capture serves the western enterprise (and education) markets so well.
Of course, I may well have misunderstood the proposal and be barking up
the wrong tree here.

> *Auto-Collection*

Will look forward to this discussion. The current behaviour of shoving
everthing into the Personal Address Book (including cards in other
addressbooks) seems to leave plenty of room for improvement.
Duplicating user's data can't be a good thing.

Cheers -

Leni.

[Bryan W Clark]

mozil...@zindus.com wrote:

Hi Bryan, some comments follow.

Zimbra

Unfortunately there doesn't seem to be a public normative reference for Zimbra's contact fields.  But this is what it supports:
- first
- last
- middle

Excellent, this is good to get additional data points for other systems.

In addition, the:
- fullName
field maps to Thunderbird DisplayName but it is *read-only*, and generated by a policy, eg:
- Last, First
- First, Last
- Company
- Last,First (Company)
- etc.

The way to change this "read-only" field is to write to first, last and middle.  fullName is generated according to policy.

One can easily imagine policy-generated DisplayName being a feature that the enterprise market might insist upon.  So I wonder how this way of thinking about DisplayName sits with the proposal to drop first/middle from the capture interface?

It might be good to have a use-case around this.  ie. how would a user edit a contact's name when their addressbook was synced with a company using policy-generated DisplayName.

Differences between the vendors

In terms of subdividing DisplayName, the odd one out seems to be Google.  All the rest support the up-front capture of (at least) first and last.

One can certainly imagine displayName-only capture offering more uniform semantics across western and non-western cultures.  Presumably that's the choice Google made.  But I do wonder whether displayName-only capture serves the western enterprise (and education) markets so well. Of course, I may well have misunderstood the proposal and be barking up the wrong tree here.

There's an important difference between our Thunderbird address book storage scheme and an LDAP or other system; mostly based on how people use them but also based on needs of those other systems.  We want to simplify our address book, yet make it powerful and extensible such that people can build interesting things on top of it and it also works very well with LDAP and other address book syncs. 

The display name policy inside Thunderbird is a simple boolean variable accessible via the about:config interface.  This allows for swapping the first name, last name generated in the displayName.

    mail.addr_book.displayName.lastnamefirst = default:(false)

Different from the view change, which alters how you see the data and not how it's stored.
    mail.addr_book.lastnamefirst = 1


For editing an existing addressbook entry, on either an LDAP system or the thunderbird local storage system there is no policy rewrite that thunderbird performs.  When the displayName entry is blank (for instance a new contact) Thunderbird will genereate a display name in a specified policy format, however editing any of the first/last name attributes of an existing card won't apply a policy change on the displayName.  Enterprise LDAP systems may make this policy change on the server side such that you update a last name and the CN entry is updated according to policy but that is mostly an issue outside of this part of Thunderbird.

So by default thunderbird local entries could keep a single name entry while allowing any number of additional name entry types.  And when a name is imported from another contact database, such as an LDAP system, we store the additional breakdown of attributes in our local system using annotations to describe the different types.  The XML representation example shows how additional name policies from other systems stored in Thunderbird could be represented.

> *Auto-Collection*

Will look forward to this discussion.  The current behaviour of shoving everthing into the Personal Address Book  (including cards in other addressbooks) seems to leave plenty of room for improvement. Duplicating user's data can't be a good thing.

There are some separate issues surrounding address collection, in another email I'll get into this more.

~ Bryan

[mozil...@zindus.com]

Hi Bryan -

I still think it'd be good to see use-case around this.

I get the feeling I'm misunderstanding the proposal. But if I
understand correctly, it looks to me as if (under the proposal), users
who synced their addressbooks against policy-generated DisplayName
repositories wouldn't be able to sync *any* of their contacts' name
fields. Not FirstName, LastName or DisplayName.

1. scenario: edit in Thunderbird:
- change DisplayName
- sync
- no change to remote FirstName or LastName
(and therefore no change to policy-generated DisplayName)

2. scenario: edit at Remote:
- change FirstName or LastName
- sync
- no change to DisplayName
- (FirstName or LastName may change but these aren't displayed)

If this is right, it seems like a backward step for those folks? They'd
have to edit DisplayName in Thunderbird and First+Last remotely.

Also, just wondering whether "Address" is on the agenda to be tackled
too? Not as important as the name fields, but similar issues apply with
significant differences in the way Thunderbird handles them vs other
vendors.

Leni.

> Enterprise LDAP systems /may/ make this policy change on the server side

> such that you update a last name and the CN entry is updated according
> to policy but that is mostly an issue outside of this part of Thunderbird.
>
> So by default thunderbird local entries could keep a single name entry
> while allowing any number of additional name entry types. And when a
> name is imported from another contact database, such as an LDAP system,
> we store the additional breakdown of attributes in our local system
> using annotations to describe the different types. The XML
> representation example shows how additional name policies from other
> systems stored in Thunderbird could be represented.
>
>>> *Auto-Collection*
>> Will look forward to this discussion. The current behaviour of
>> shoving everthing into the Personal Address Book (including cards in
>> other addressbooks) seems to leave plenty of room for improvement.
>> Duplicating user's data can't be a good thing.
> There are some separate issues surrounding address collection, in
> another email I'll get into this more.
>
> ~ Bryan
>

> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird

[Bryan Clark]

mozil...@zindus.com wrote:
> Hi Bryan -
>
> I still think it'd be good to see use-case around this.

Good point, a simple use case I've been for the address book names has
been the collection of addresses, two systems one manual and one automatic.

For the automatic collection we take from addresses you've sent mail
to. So when you compose mail to me you'll get my clarkbw address
entered into your address book automatically for next time. With a
system of first/last name splitting the code will have to decide inline
how to best break up my name and will often make mistakes at this.

For manual addition of addresses into the address book I'd like to see
us do some nicer, much quicker methods of collection than the large
dialog we popup right now. Instead we could try to re-use some of new
firefox widgets like the bookmarking popup.

see for example:
http://clarkbw.net/designs/add-contacts/add-contact-inline.png

The large dialog is a bit intimidating and assumes you have or want to
enter in a lot more information about the person than were given at that
moment; an assumption that could be true but I believe it's mostly
false. Most often I believe that people just want to save someones
email address to use later, but we still give a way to get to the large
editor if they want to do more.

>
> I get the feeling I'm misunderstanding the proposal. But if I
> understand correctly, it looks to me as if (under the proposal), users
> who synced their addressbooks against policy-generated DisplayName
> repositories wouldn't be able to sync *any* of their contacts' name
> fields. Not FirstName, LastName or DisplayName.

Yes, I think we're still disconnected here.

> 1. scenario: edit in Thunderbird:
> - change DisplayName
> - sync
> - no change to remote FirstName or LastName
> (and therefore no change to policy-generated DisplayName)

Let me setup this one a bit more so I feel like we can connect better
because I don't understand the scenario as there are some still
difficult and unanswered questions. The key is to do what we think is
right for our users in any of these cases and make the data work for
them, not the other way around; so we shouldn't let our schema system
divert from what people actually want.

1. scenario: edit LDAP address book card in Thunderbird
- change DisplayName
-- a "cn" or "commonname" write gets sent to the LDAP server
-- the LDAP server has a name policy it imposes and that policy changes
the FirstName and LastName attributes
-- with an LDAP server which has notification support we could recieve a
change notif and sync our contacts attributes
- Next time the user searches for the name as they edited Thunderbird
uses the name correctly as it searches the name field by default
-- an LDAP query could happen at this time, updating the attributes if
there was no change notification

The user in this scenario updates an entry that Thunderbird uses at it's
default search entry, the display. The updated name is used when user
goes to auto-complete for that name.

1a. scenario: edit Thunderbird address book card, sync with Mac Address Book

- change DisplayName
- sync

-- since the Mac Address Book requires a first/last name split we're
going to have to do something and split it the best we can during the sync
-- There is no name policy for Mac Address book wrt display name

> 2. scenario: edit at Remote:
> - change FirstName or LastName
> - sync
> - no change to DisplayName
> - (FirstName or LastName may change but these aren't displayed)
2. scenario: edit at Remote
- change FirstName or LastName

- sync Thunderbird
-- DisplayName changes if there was a policy that changed the remote
DisplayName; Thunderbird gets that change on the sync
-- FirstName and LastName are changed in Thunderbird and changes shown

First and Last names _are shown_ when they are given by a remote system,
or added by someone who wants to add the additional information.

I tried and guess I failed to show this working in my ascii example of a
Manual Entry from my first mail. If you look at that example I was
hoping to show how the extra attributes are displayed and editable,
however Name (the default) is the only one that's required by the UI.

>
> If this is right, it seems like a backward step for those folks?
> They'd have to edit DisplayName in Thunderbird and First+Last remotely.

I think what I really wasn't clear on before was that I'm thinking of
the Thunderbird address book as being both a cache and and overlay.
Correct me where I go wrong. People using thunderbird want fast address
book lookups and offline address book information. At the same time
people don't want (and it doesn't make sense for) Thunderbird to
necessarily suck down an entire company LDAP; but we can grab the ones
we need and mark them as a cache of the LDAP so they always update to
what is remote when it's possible.

Fast, Offline, Sync'd are the things this is suppoesd to achieve.

At the same time we want to be extensible for other systems to do
interesting things inside our address book, this is what the overlay is
about. On top of a remote address book we want to think about storing
additional things that help make managing all our mail and contacts easier.

[ Thunderbird Address Book ]
+ type = ldap-cache??
+ entered tags
+ machine tags
+ blog
+ facebook, linked in, amazon (other web ids)
+ extension references
[ Remote Address Book ]
( basic set of attributes )

> Also, just wondering whether "Address" is on the agenda to be tackled
> too? Not as important as the name fields, but similar issues apply
> with significant differences in the way Thunderbird handles them vs
> other vendors.

Yes, actually you nailed it again! A very similar set of problems. I'm
assuming you're talking about the Postal Address fields. There are
problems with getting the correct fields for people to enter, is it a
state or a proviince. And just like the name field you can't rely on
locale to help you out since I can know people with Chinese names and
addresses and we each would have problems storing contact info if locale
was used to show us each a certain type of UI.

Cheers,
~ Bryan

[Ron K.]

Bryan Clark keyboarded, On 4/22/2008 8:53 PM :

> mozil...@zindus.com wrote:
>> Hi Bryan -
>>
>> I still think it'd be good to see use-case around this.
> Good point, a simple use case I've been for the address book names has
> been the collection of addresses, two systems one manual and one
> automatic.
>
> For the automatic collection we take from addresses you've sent mail
> to. So when you compose mail to me you'll get my clarkbw address
> entered into your address book automatically for next time. With a
> system of first/last name splitting the code will have to decide
> inline how to best break up my name and will often make mistakes at this.
>
> For manual addition of addresses into the address book I'd like to see
> us do some nicer, much quicker methods of collection than the large
> dialog we popup right now. Instead we could try to re-use some of new
> firefox widgets like the bookmarking popup.
>
> see for example:
> http://clarkbw.net/designs/add-contacts/add-contact-inline.png
>
> The large dialog is a bit intimidating and assumes you have or want to
> enter in a lot more information about the person than were given at
> that moment; an assumption that could be true but I believe it's
> mostly false. Most often I believe that people just want to save
> someones email address to use later, but we still give a way to get to
> the large editor if they want to do more.

Wow, I like that, its very much to the point and right on the screen
next to the messages address field. All it needs is a drop down listing
the books a user is maintaining. I currently use two in addition to the
defaults.

>
>
>> Also, just wondering whether "Address" is on the agenda to be tackled
>> too? Not as important as the name fields, but similar issues apply
>> with significant differences in the way Thunderbird handles them vs
>> other vendors.
> Yes, actually you nailed it again! A very similar set of problems.
> I'm assuming you're talking about the Postal Address fields. There
> are problems with getting the correct fields for people to enter, is
> it a state or a proviince. And just like the name field you can't
> rely on locale to help you out since I can know people with Chinese
> names and addresses and we each would have problems storing contact
> info if locale was used to show us each a certain type of UI.
>
> Cheers,
> ~ Bryan
>

We currently have these:

general.useragent.locale default string en-us
mailnews.reply_header_locale user set string en-us

Could one of these also permit a comma separated series of locales that
form a precedent sequence for formatting Postal Address or other
fields. Meaning the dialog would get smarter and label fields as State
for en-us but Provence for en-cdn. Fx has the Lang precedent dialog to
denote acceptable languages.

I will take this a step farther, add a field to the address card to
enter the recipients local and reuse the Fx Language dialog with it's
laundry list to make the selections. Now a database of strings could be
stored that are flags to First/Last pref and other fields that flip
depending on locale norms. The old NC4.xx used strings of pseudo-script
to store thread pane sequence and width info as well as per news group
retention preference.

To my mind, when all is done, LDAP should be usable again (Or what ever
the industry superceeds it with.), so sharable address data results. To
me a nice goal is an address data base that I can use as a desktop item
and from within Tb. Then I could print address labels for my snail mail.

--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!

[Bryan W Clark]

Ron K. wrote:
> Bryan Clark keyboarded, On 4/22/2008 8:53 PM :

>> For manual addition of addresses into the address book I'd like to
>> see us do some nicer, much quicker methods of collection than the
>> large dialog we popup right now. Instead we could try to re-use some
>> of new firefox widgets like the bookmarking popup.
>>
>> see for example:
>> http://clarkbw.net/designs/add-contacts/add-contact-inline.png
>>
>> The large dialog is a bit intimidating and assumes you have or want
>> to enter in a lot more information about the person than were given
>> at that moment; an assumption that could be true but I believe it's
>> mostly false. Most often I believe that people just want to save
>> someones email address to use later, but we still give a way to get
>> to the large editor if they want to do more.
>
> Wow, I like that, its very much to the point and right on the screen
> next to the messages address field. All it needs is a drop down
> listing the books a user is maintaining. I currently use two in
> addition to the defaults.

Oh, good idea. I bet we could continue stealing components of the
firefox dialog, like the bookmarks folder chooser, for that part. I'm
not sure all of the behavior of the firefox dialog is what we want,
however I think it would be beneficial if we kept close to it.

> We currently have these:
>
> general.useragent.locale default string en-us
> mailnews.reply_header_locale user set string en-us
>
> Could one of these also permit a comma separated series of locales
> that form a precedent sequence for formatting Postal Address or other
> fields. Meaning the dialog would get smarter and label fields as
> State for en-us but Provence for en-cdn. Fx has the Lang precedent
> dialog to denote acceptable languages.
> I will take this a step farther, add a field to the address card to
> enter the recipients local and reuse the Fx Language dialog with it's
> laundry list to make the selections. Now a database of strings could
> be stored that are flags to First/Last pref and other fields that flip
> depending on locale norms. The old NC4.xx used strings of
> pseudo-script to store thread pane sequence and width info as well as
> per news group retention preference.
>
> To my mind, when all is done, LDAP should be usable again (Or what
> ever the industry superceeds it with.), so sharable address data
> results. To me a nice goal is an address data base that I can use as
> a desktop item and from within Tb. Then I could print address labels
> for my snail mail.
>

Right on! I like where you're going with that train of thought. It is
really important to keep the remote sources usable for many obvious
reasons.

David recently brought up a good point about the Mac Address Book and
how we need to keep properly sync'd with that. While we might want to
do more in our Thunderbird address book but we also want people to be
able to sync addresses with their portable devices like the iPhone; and
so perhaps we treat the system address book like a remote source to sync
with. Other desktops should have similar evaluations about how to
integrate with system address books, if available.

~ Bryan

[Ron K.]

Bryan W Clark keyboarded, On 4/24/2008 11:23 AM :

> Ron K. wrote:
>> Bryan Clark keyboarded, On 4/22/2008 8:53 PM :
>

Trying to get back into the mind set I was in when I wrote the above.
Each local build sets it's own default locale string for
general.useragent.locale, as I understand things. Yet as been pointed
out in this thread and one on Filtering based on Script, there can be
mismatches between the Tb global locale and specific case needs. Having
an associated locale persisted as a Abook field may be an aid to
syncing. Then you could apply logic to sequence data fields for a target
locale other than the default.

As an extension of the iPhone or other cell phone case, would an Abook
Global pref aid in that. Ideally all of the devices would support a
generic standard, at least for basic data. However for some,
proprietary formats are a foundation for competitive advantage features.
Those will be harder to sync with. With a Abook UI pref the user would
enter a string for their brand of device. Then apply that to a lookup
table to pull a string that sequences the data fields of Abook into the
devices prefered order. You may also have to pull from that table some
field name translations. Some of the LDAP fields come to mind like it's
"CN".

With the supporting code done the UI could offer the user some Export
and Send To... options. Things like send to LDAP or other directory
server or Send to iPhone. The export could be restructured for Outlook
or Exchange. (Davids future enterprise goal) For the LDAP server, I
have raised the question before of running one localy. My vision of
this is, it becomes a shared resource for any XULRunner application. A
disclaimer here, the server could be another protocol. You could
redesign the Abook as an XULRunner app using the same GRE as Tbird, yet
be able to be run in standalone mode as an open source alternative to OS
provided apps. I am thinking the MS Windows Address Book here.

Something else I think is related is expanding Abook to support more IM
than AIM. Presently several products are using libpurple to power
multiple IM formats simultainiously. Pidgon is one, and the new
Instantbird (an XULRunner app) another, that use the library. DavidA
mentioned libpurple during one of the brainstorming threads He started.

Enough for now.

[Mark Banner]

Bryan Clark wrote:
> see for example:
> http://clarkbw.net/designs/add-contacts/add-contact-inline.png

That is really nice, much better than what we have at the moment.

Standard8

[Mark Banner]

Bryan W Clark wrote:
> *Where do (and can) we use Contact Names?*

>
> Mainly we use the contact name field in searches for auto-complete in
> the compose window or searching the address book for a certain contact.
> But currently there is no sorting by first name, last name, or other
> types of names. Search is performed on all the name fields, but on them
> as a whole because it's generally cumbersome to do otherwise. Separated
> name fields do not necessary improve search results, with an indexed
> database even a large set of names can be searched very quickly for the
> system and more importantly for the user via a single entry.

Just wanted to expand on this a little. There's one case that
immeditately comes to mind, is that when displaying the headers of
messages, if the address of the user matches one in the address book,
then we'll shorten the address so that you just get the name from the
address book (i.e. not the email as well).

Also, there is a bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=243631), where it is
proposed (if I remember correctly) that the name from the address book
is used in the From and To columns of the list of mails display.

> *Possible XML Representation Example*
> *Possible Example Manual Entry*

These seem like good ideas. Obviously as per other parts of the thread
we need to ensure we'll have a consistent implementation and ways of
interfacing to the various different types of address books.

Standard8

[Bryan W Clark]

Mark Banner wrote:
> Bryan W Clark wrote:
>> *Where do (and can) we use Contact Names?*
>>
>> Mainly we use the contact name field in searches for auto-complete in
>> the compose window or searching the address book for a certain contact.
>> But currently there is no sorting by first name, last name, or other
>> types of names. Search is performed on all the name fields, but on them
>> as a whole because it's generally cumbersome to do otherwise. Separated
>> name fields do not necessary improve search results, with an indexed
>> database even a large set of names can be searched very quickly for the
>> system and more importantly for the user via a single entry.
>
> Just wanted to expand on this a little. There's one case that
> immeditately comes to mind, is that when displaying the headers of
> messages, if the address of the user matches one in the address book,
> then we'll shorten the address so that you just get the name from the
> address book (i.e. not the email as well).
>
> Also, there is a bug
> (https://bugzilla.mozilla.org/show_bug.cgi?id=243631), where it is
> proposed (if I remember correctly) that the name from the address book
> is used in the From and To columns of the list of mails display.

I'll make a comment in the bug, something like what is being proposed
should probably be the default behavior.

~ Bryan

[Praveen]

it would be good if nickname could be reflected in the inbox. for
example. my friends name is Bruce Banner. i however call him Batman.
and i would like his name to show up as Batman in my inbox as apposed
to the name he might have chosen for himself. this is not quite a
address book thing but it is related

Bryan W Clark wrote:
> There are a number of pages already dedicated to address book card
> fields and I wanted to work through a bunch of fields to get some
> discussion going about how we use them.
>
> http://wiki.mozilla.org/MailNews:Address_Book_Card_Fields
> http://wiki.mozilla.org/MailNews_Talk:Address_Book_Card_Fields
> http://wiki.mozilla.org/MailNews_Talk:Address_Book
>
> This message, as the subject indicates, is about the name field;
> dissecting what others are doing along with what we are doing. Then
> looking at how we are using this field to understand further what we
> should be doing. In general, I'm look for systems that simplify the
> common cases, yet are extensible enough to offer enhancing and advanced
> systems the ability to build and integrate upon. Sorry this gets a bit
> long for an email.
>

> *Current Thunderbird*

> 4 default and distinct fields for the name:
>

> * First
> * Last
> * Display (generated by first and last)
> * Nickname
>
> *Other Address Books*

> (this could be an en-us only view of all these systems, help appreciated)
>
> Mac Addressbook [1]
>

> * Name pronunciation
> * First name
> * Last name
>
> Google Contacts [2]
>
> * Title (singular - represents contacts name)
>
> Yahoo Address Book [3]
>
> * First
> * Middle
> * Last
> * Nickname
>
> Windows Live Mail [4]
>
> * First
> * Last
> * Nickname

>
> vCard [5], hCard [6]
>

> * fn
> * n
> o family-name
> o given-name
> o additional-name
> o honorific-prefix
> o honorific-suffix
> * nickname (multiple)
>
> JavaPhone [7]
>
> * N
> o 0 FAMILY_NAME
> o 1 GIVEN_NAME
> o 2 ADDITIONAL_NAMES
> o 3 PREFIXES
> o 4 SUFFIXES
> * FN
> * NICKNAME
>
> *Naming Conventions*

>
> Many of the more complex systems are similar because they are based on
> the X.520 attributes, while others (like google) offer a more simplistic
> version. Localization and naming conventions [8] are a very difficult
> problem presented to the address book naming system. Some cultures
> place the Given Name [9] before the Family Name [10] (often called last
> name) while others place it after or use no Family Name at all.
>
> This tends to make the interface for names difficult because the
> ordering and naming needs to be completely variable depending on
> locale. Not only is the UI for manual entry difficult to design, but
> attempting to parse up different names into the proper structure is
> almost always going to yield incorrect results.
>

> *Where do we get Contacts?*

>
> How does Thunderbird acquire new contacts into it's local address book.
> Several methods of which most are automatic and some are manual.
>

> * auto-collection of addresses
> * manual contact entry
> * import
> * contact sync
>
> *Auto-Collection*

>
> During use of Thunderbird we expect that contacts will (by default) be
> automatically collected as we send messages out via reply or new
> compositions. Collection brings a number of issues we don't need to
> discuss here, suffice it to say that we should know addresses we've
> collected from the ones we've entered.
>

> *Manual Entry*

>
> Manual entry by a person, typing in a name with email address uses the
> address book entry interface; other options are possible but not covered
> here. This is the least optimal way for a person to enter their
> addresses into Thunderbird, it's slow and prone to lots of typos and
> errors. Currently a person can enter in the First and Last name fields
> which auto-populates the Display Name field. An alternate Nickname
> field can be entered as well.
>

> *Import*

>
> Importing contacts from other systems, LDAP, Outlook, or other address
> books. Other systems use different fields for different purposes, even
> if we don't match their exact field naming we should try to not destroy
> the way they contain their information such that we can have a
> compatible way to export the data we imported.
>

> *Sync
>
> *Sync with PDAs and mobile devices, these like the Import often have

> different fields and field types which we should maintain, however our
> system may not use them.
>

> *Where do (and can) we use Contact Names?*

>
> Mainly we use the contact name field in searches for auto-complete in
> the compose window or searching the address book for a certain contact.
> But currently there is no sorting by first name, last name, or other
> types of names. Search is performed on all the name fields, but on them
> as a whole because it's generally cumbersome to do otherwise. Separated
> name fields do not necessary improve search results, with an indexed
> database even a large set of names can be searched very quickly for the
> system and more importantly for the user via a single entry.
>

> *What we need to gather thoughts about*

>
> Seeing as the distinctions of first (given) name, last (family) name,
> and display are a bit confusing and error prone I think we should move
> the entry interface to only show one name type by default and allow for
> other name types to be entered as additional if desired.
>
> This change will shorten up the interface to a default of 1 entry plus
> the [add entry] line, cutting it's size in half. Additionally it will
> simplify the entry to a single line which isn't prone to
> internationalization differences, entries are recorded exactly as they
> are written or recieved and we can assume that is how they want to
> receive them as well.
>
> This does not mean, however that we shouldn't hold additional first and
> last name data and display the differences; take for example the import
> or sync case. In fact by allowing many names associated with a person
> but each having different types we can accomidate many more name
> variations mimicing what the JavaPhone or other complex systems make
> available. Yet the default will still be how Thunderbird sees the name
> written out.
>

> *Possible XML Representation Example*

>
> All names are still a type name field such that we search across all
> names during auto-complete and other search usage. During imports and
> syncs we keep the separations that are presented to us and search across
> all of them. The likely default for most peoples address books names
> will be a default only.
>
> <name type="default">Davy Crockett</name>
> <name type="nickname">Davy</name>
> <name type="first">David</name>
> <name type="last">Crockett</name>
>
>

> *Possible Example Manual Entry*

>
> The Address Card entry uses a single name entry by default, but allows
> people to expand the names into additional columns.
>
> Name: { Davy Crockett }
> [ add additional names ] e.g. nickname
>
>

> *Possible Example Manual Entry Edit */(editing an imported contact)/

[mozil...@zindus.com]

Hi Bryan -

The abbreviated contact capture UI is much less scary!

On the first/last/display name, here is the use-case I wonder about.

Background

The user is synced with an Enterprise repository for which FirstName and
LastName are read/write and DisplayName is read-only from Thunderbird's
perspective. In other words, if the user wants to change the
repository's DisplayName from Thunderbird, they have to edit FirstName
or LastName and the repository policy-generates DisplayName.

Contact Capture

In the proposed abbreviated UI, only DisplayName gets entered. So it
falls to sync to generate FirstName and LastName from DisplayName.

Question: is it more or less likely for there to be errors with sync
doing this job vs asking for first+last up-front via the UI? My guess
is sync isn't going to do as good a job as explict capture. Here is an
example: "Robert De Castella".

Under the current UI, the user enters:
FirstName: Robert
Lastname: De Castella
DisplayName: Robert De Castella (auto-generated by UI)

Under the proposed abbreviated UI, the user would type:
DisplayName: Robert De Castella
and the sync would have to do it's best to work backwards
to First+Last. My guess is that it would end up with:
FirstName: Robert
LastName: Castella

Mmm...

Something to consider: compromise on an abbreviated capture UI with:
FirstName/Lastname/DisplayName/Email. Not as nice though.

I wouldn't argue that the interests of this group of users (people
synced with universities and enterprises) should rule the roost, it's
just good to be clear about the tradeoffs.

Cheers -

Leni.

[Ron K.]

I relooked at the example and got an idea. Why not make the popup an
editable text form with Tb offering a guess, and if the case Leni
presented happens, the user could edit the First and or Last fields
before clicking OK. Clearly the code for the example has to parse the
displayed sender data to separate the pretty name from the actual e-mail
address. Let the code guess from a ltr scan the first and last names.

We also get other cases such as
military rank prefix: SFC Alvin York
people with professional degrees: Dr. Jonas Salk, M.D. or Dr.
Albert Einstine Ph.D.
persons with name lineage: Sr., Jr., III, etc.

So the idea can break for these cases and need manual intervention. Over
all I prefer the quick compact concept Brian proposed. The clickable
icon in the address bar is a neat UI touch I missed the first time I
looked at the screen shot.

Ron K.

mozil...@zindus.com keyboarded, On 4/28/2008 10:09 PM :

[Bryan Clark]

I wonder if there is a way to understand this policy from Thunderbird.
Much of these problems seem to be that there exists a policy on the
server and I'm not aware if Thunderbird can understand that. I have to
assume that Thunderbird would know if certain fields were read-only or
read-write.

mozil...@zindus.com wrote:
> Hi Bryan -
>

I think my guess here would have been
FirstName: Robert
LastName: De Castella

Or even if it messed up
FirstName: Robert De
LastName: Castella

Just on the assumption that we would try to not discard information
where possible.

>
> Mmm...
>
> Something to consider: compromise on an abbreviated capture UI with:
> FirstName/Lastname/DisplayName/Email. Not as nice though.

This brings up my question. If we take your scenario above, then we can
end up with situations where people edit the DisplayName and that
information is lost. Just assume that the above name is "Robert De
Castella Jr." and with the FirstName, LastName entries available a
person enters the correct information in each. Then they fix the
DisplayName to add the "Jr." in because it is his full name. The "Jr."
information is lost since that field was read-only and it seems we're in
just as bad a situation.

FirstName: Robert
LastName: De Castella
DisplayName: Robert De Castella Jr. -> "Jr." piece gets lost.

We could change the DisplayName to be view only instead of editable, but
that doesn't help things overall.

> I wouldn't argue that the interests of this group of users (people
> synced with universities and enterprises) should rule the roost, it's
> just good to be clear about the tradeoffs.

We may need to think about a separate UI for remote systems that have
policy like this since we can't seem to the solve the problems of a
person with a local address book and a person with an Enterprise LDAP
address book with displayname policies. But it seems like some more
investigation into our open questions would help us decide more.

There are generally two systems against each other here. Database
fields with the correct view of the world vs. the user interface with
the correct view of the world.

If you lean towards entry of FirstName, LastName and allow the
DisplayName to be set by policy (cn="firstname lastname") you risk names
being incorrectly created for the DisplayName and where they are going
to be seen as a mistake. However you are more likely to have a correct
database of contacts, this doesn't necessarily do more for people using
the system only that it gives you a more correct database for it's own sake.

If you lean towards the DisplayName and allow the script policy to fit
that into the FirstName, LastName then you have a database that is
incorrect at the same percentage as the other case but the person will
likely never know. As long as the DisplayName is what is displayed and
always matches what was entered the FirstName and LastName could be
somewhat incorrect like the example above. Only in a system that shows
FirstName and LastName separately for sorting or other purposes would a
person detect the incorrect data fields, and outside of the contact
editor only the DisplayName is used.

Cheers,
~ Bryan

[ovidiu]

I support the idea of *tagging contacts*, but even more *tagging
fields*(names).
The point is, I support the idea of *field names as tags*
-first/last/nick etc, but also the idea of a [+] "add more.." as it
should probably pop in many other areas, emails for sure, phone numbers
etc. These are tools that allow later offer of more or different /custom
default contact panel fields without deep core changes.. While some
combination of fields may lead to various "views" of the contact.

I think it's all about having a flexible enough system to be further
improved with only "surface" work

-I see this as 2 separate issues.
1. First is about names themselves,
*for this, there should definitely be the option to add more names (like
copied from another post) with a +

Name: { Davy Crockett }
[ First Name ]: { David }
[ Last Name ]: { Crockett }

[ Nickname ]: { Davy Crockett }[+]

[ add additional names ] e.g. nickname

while the title "first name" is rather a *tag for the field*. In this
way, the UI has more flexibility and is easier modified later to adjust
to sync or other needs.
(there are many cases, common 4 names in Latin America, other concept on
first/family name in Arabic cultures, or current names with De .. or La
or hyphen family names like xxx-yyy. )

2. About the various display methods, there could be "views" of the same
contact, that extract the info from those various names and niks
considering their tags. One may use a tipe of military description with
titles etc, but on personal level may use normal names and for mommy
will always be little johny.
*I describe this like a reversed idea similar to identities, where
fields with various tags may help parse different incoming id for what
view is suitable.
*I see this as a workaround for dealing with the complex name standards
in different cultures.

[ examples, FWIW:
- a very simple example would be that in RO (and probably other
countries) in an official school list I would be listed alphabetically
by family name (I'd be going for G -grigorescu) while on a not so
different country, Portugal, school lists are always using the First
name (I would go there for O -ovidiu). This sort of view vs tags (field
names) may help "translate" such small to bigg issues.
- I found myself in cases (weird paperwork ..) where I was supposed to
state *first name*/*initial* (or full) from first name of father/*family
name*. For such, there may be interesting to have a field for that too.
Of course, custom added, tagged accordingly ..
- a more dramatic difference is with arabic names, where a girl
colleague had to "assimilate" a name for Last/Family name in all the
papers (residence and passports, but also school etc). Which it was
actually her father's name, but I understand it was not very accurate,
more of a workaround. I won't develop on that as I'm not sure of the
accuracy of my info, but there are different perspective on these, so
she would use those names/fields in different combinations for home and
euro ways ..

[ovidiu]

Ron K. wrote:
> I relooked at the example and got an idea. Why not make the popup an
> editable text form with Tb offering a guess, and if the case Leni
> presented happens, the user could edit the First and or Last fields
> before clicking OK. Clearly the code for the example has to parse the
> displayed sender data to separate the pretty name from the actual
> e-mail address. Let the code guess from a ltr scan the first and last
> names.
>
> We also get other cases such as
> military rank prefix: SFC Alvin York
> people with professional degrees: Dr. Jonas Salk, M.D. or Dr.
> Albert Einstine Ph.D.
> persons with name lineage: Sr., Jr., III, etc.
>
> So the idea can break for these cases and need manual intervention.
> Over all I prefer the quick compact concept Brian proposed. The
> clickable icon in the address bar is a neat UI touch I missed the
> first time I looked at the screen shot.
>
> Ron K.

I was thinking about these multiple names and names with particles. I

see this as 2 separate issues.

1. First is about names themselves, where there are many cases, common 4

names in Latin America, other concept on first/family name in Arabic

cultures..
*for this, there should definitely be the option to add more names with
a [+]
while the title "first name" is rather a tag for the field.
2. For the various display methods, there could be "views" of the same

contact, that extract the info from those various names and niks
considering their tags.

I described this extensively in another post, point being that such
fields vs tags vs views, may help Tb better parse for incoming addresses
vs identities.

[Leni]

Just to create a reference from this thread to a related Google gdata
defect/enhancement request. The user wants to sync from Gmail
(display-name-only) to a mobile device.

http://code.google.com/p/gdata-issues/issues/detail?id=565

Leni